#172 A long duration call is automatically repeated

[Christian Foltin]

Dear OpenORB-Team,

thanks for your great product! Fantastic.

Unfortunately, if noticed an error in the
SSL-implementation.

In our real case application, we have a call that takes
a *very* long time to gets executed. Without SSL,
everything is ok. The client waits until the server
returns.

But, using your SSL implementation, the client is bored
after a while and repeats the call. This is surely not
intended.

You can verify this behaviour adding the following
lines to your example
SSL/src/examples/org/openorb/orb/examples/ssl/basic/Server.java

public void hello( String msg )
{
System.out.println( "#### Message from client:
'" + msg + "'" );
/* delay for a very long time: */
try {
while (true) {
System.out.println("Waiting...");
Thread.sleep(1000);
}
} catch (Exception e) {
}
}

You'll probably get the following output:

Binding information for object class
org.openorb.orb.examples.ssl.basic._ISecureStub:3a835d
Repository IDs from Object:
IDL:org/openorb/orb/examples/ssl/basic/ISecure:1.0
IOR #0 (orginal IOR)
Published RepoID:
IDL:org/openorb/orb/examples/ssl/basic/ISecure:1.0
Bound profiles: 1
Profile #0 endpoint: iiop:1.2@sit00037.rsint.net:1752
OpenORB Nonpersistent Object Key:
.OO.[í.. ....POA. 004F4F01 5BEDAA3E 05010000 504F41FE
ąX.. B1583DA7
Components:
ComponentID = 1 (TAG_CODE_SETS)
For char data:
SNCS:0x100204e4 'Cp1252' 'IBM-1252 (CCSID
01252); MS Windows Latin-1'
SCCS:0x0001000f 'ISO-8859-15' 'ISO/IEC
8859-15:1999; Latin Alphabet No. 9'
SCCS:0x00010001 'ISO-8859-1' 'ISO
8859-1:1987; Latin Alphabet No. 1'
SCCS:0x00010020 'US-ASCII' 'ISO 646:1991
IRV (International Reference Version)'
For wchar data:
SNCS:0x00010109 'UTF-16BE' 'ISO/IEC
10646-1:1993; UTF-16, UCS Transformation Format 16-bit
form'
SCCS:0x00010100 'ISO-10646-UCS-2' 'ISO/IEC
10646-1:1993; UCS-2, Level 1'
ComponentID = 20 (TAG_SSL_SEC_TRANS)
target supports: 0x00E7 ->
NoProtection(0x0001),Integrity(0x0002),Confidentiality(0x0004),EstablishTrustInTarget(0x0020),EstablishTrustInClient(0x0040),NoDelegation(0x0080)
target requires: 0x0066 ->
Integrity(0x0002),Confidentiality(0x0004),EstablishTrustInTarget(0x0020),EstablishTrustInClient(0x0040)
port: 1684

The server is ready...
#### Message from client: 'Hello from client!'
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
#### Message from client: 'Hello from client!'
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...

Please do not hesitate to get back to me, if there are
any questions.

The behaviour was shown for the versions 1.3.1 and
1.4.0beta2.

Yours,

Chris