[omniORB] Delay when calling callback to Java first time

Sai-Lai Lo S.Lo@uk.research.att.com
01 Aug 2000 10:03:38 +0100


Your trace indicates that omniORB is waiting for a reply to a locate
request it issued to the java client. Presumably it is not receiving
anything for 30s. I suggest you turn the tracing level up on omniORB to
"-ORBtraceLevel 30" to see exactly what and when the reply comes. Also check
if the oneway is indeed delivered to the client.

I can't explain the behaviour of the java client, may be it is a bug that
you should report to Sun.

A possible workaround is to tell omniORB not to check for object existence
on first invocation. To do so, use "-ORBverifyObjectExistsAndType 0".

Sai-Lai

>>>>> Viktor Mikho writes:

> I am not sure if I am doing something wrong or it is a genuine problem.
> I have Java 1.2 client and omniOrb 2.8 server on NT4.
> Java client creates at some stage callback object:

>     m_monitor =3D new ProgressMonitorImplJ(m_deviceRequestTable);
>     m_orb.connect(m_monitor);

> Then this callback object is registered with the server:

>     m_mgrRef.registerCallback(m_monitor);

> When time comes, server tries to call oneway method uploadeStateChanged()=
 using the m_monitor. It
> works fine but the very first time when method on this object is called t=
here is a 30 seconds
> delay. Consecutive calls take fractions of seconds. I used a debugger to =
see what happens. Here is
> a sequence of calls:

> _proxy_ProgressMonitor::uploadeStateChanged(const DeviceRequestT & u)
> ....
>   OmniProxyCallWrapper::one_way(this, _call_desc);
> ....
> if (omniORB::verifyObjectExistsAndType)
o-> assertObjectExistent();
> ....
> switch (_c.IssueLocateRequest(rak.key(),rak.keysize()))
> ....
> get_char_array((CORBA::Char*)hdr, sizeof(MessageHeader::HeaderType),
> 		omni::ALIGN_1, 1);

> Something within get_char_array blocks for 30 seconds =96 I could not tra=
ck it using debugger.

> Can anyone tell me what I am doing wrong?

> Thanks,
> Viktor

> PS.  m_monitor method is called from a dedicated thread but problem is ex=
actly the same when it is
> called from some of the server methods.








--=20
Sai-Lai Lo                                   S.Lo@uk.research.att.com
AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com=
=20
24a Trumpington Street                Tel:   +44 1223 343000
Cambridge CB2 1QA                     Fax:   +44 1223 313542
ENGLAND