RE: bugs/problems with Orbacus 4.2.2

Hi Darren,

Thank you for comprehensive answer. Please find a few comments below in the
text: 

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Darren Middleman
> Sent: Wednesday, April 13, 2005 5:40 PM
> To: Packet411 Corporation
> Cc: [email protected]
> Subject: Re: [OB-Users] bugs/problems with Orbacus 4.2.2
> 
> Hi Andrey,
> 
> > I have recently updated to Orbacus 4.2 Patch 2 from 4.2.1 and found a
> > few possible bugs in Orbacus 4.2.2 which seem to make the Orbacus
> > system work improperly:
> >
> > 1.        Now with 4.2.2, on every ORB start I'm getting a lot of
> > exceptions like
> >
> >      [java] Exception in thread "Thread-2" java.lang.NoSuchMethodError:
> >
> org.omg.PortableInterceptor.IORInterceptor_3_0.adapter_manager_state_chang
> ed
> > (Ljava/lang/String;S)V
> >
> >      [java]     at
> > com.ooc.OB.PIManager.adapterManagerStateChange(PIManager.java:688)
> >
> >      [java]     at
> >
> com.ooc.OBPortableServer.POAManager_impl.activate(POAManager_impl.java:220
> )
> >
> >      [java]     at
> com.packet411.framework.application.OrbRunner.run(Unknown
> > Source)
> >
> >      [java]     at java.lang.Thread.run(Thread.java:595)
> >
> > After printing those exceptions, my program continue to operate in
> > normal way. I have checked the Orbacus 4.2.2 source code and found
> > that the method adapter_manager_state_changed implementation is really
> > seems to be just missing in the Service Pack 2 patch source code. My
> > same code works fine with Orbacus 4.2.1 because the source code of
> > 4.2.1 doesn't contain calls to that missing
> > adapter_manager_state_changed method.
> >
> 
> Are you using Java 1.4 or 1.5?  This looks like the usual error associated
> with using newer JDKs with Orbacus.  You should make sure that you
> uncomment
> the BOOTCLASSPATH option in the config/Make.rules (Unix) or
> config\Make.rules.make (Windows) file when building Orbacus.  You should
> also use the option '-Xbootclasspath/p:$CLASSPATH' (or
> '-Xbootclasspath/p:%CLASSPATH%' for Windows) when running your
> applications.
> For example:
> 
>   java -Xbootclasspath/p:$CLASSPATH hello.Server

Right, we'have switched the entire company development to JDK 1.5. After
that switching Orbacus won't compile by default, so our build engineer
modified the makefiles according to the installation instructions included
with the patch package. The changes he made are exactly the ones you
mentioned in your answer. This helped and we got Orbacus compiled as well as
all our code. 

Unfortunately during runtime I'm still getting those "method not found"
exceptions and using "-Xbootclasspath" doesn't help. 

Do you have any positive experience of running Orbacus 4.2.2 with JDK1.5? Is
this configuration welcomed by IONA or it would be better to switch back to
4.2.1 and JDK1.4.2?

> > 2.        My other problem is with nameserv. I'm starting a mix of 4
> > processes, all making calls to each other and sending events for
> > Orbacus event service. The second start of the system causes incorrect
> > binding -- a C++ component process becomes invisible to the other
> > processes. After nameserv and eventserv are restarted everything work
> > fine again. This happens only from time to time (20-40% of all runs,
> > depending on the phase of the Moon). I'm always using rebind for
> > services registration, but it seems that in some situations Orbacus
> > 4.2.2 binds services incorrectly. This problem also was not noticed in
> > 4.2.1.
> 
> Can you give me a bit more information on what you are seeing here?  How
> are you starting these process and binding them with the naming service?
> I
> don't believe anything changed between the 4.2.1 and 4.2.2 with regards to
> the name service so I'm not sure what could be causing the problems you
> are
> seeing.  Any other information you could provide here would be helpful.

It's difficult to provide concrete details, because entire behavior of
eventserv and nameserv seems "strange" in many aspects. In particular:
- sometimes nameserv and eventserv just crash without any visible reason.
What do I mean here is that we saw several situations on our server when
those servers start and even if they experience no load at all (the modules
didn't start yet) they shut down (process just dissapears)
- in some situations eventserv start loosing too many events. Too many means
more then 20% on very low load, like 10 events sent with 1event/sec rate
- if a process that registers with nameserv goes down and then start again
it might improperly be rebinded in nameserv. This happens in approximately
50% of all module restarts. It stays registered, but when another module
tries to make call to one of methods it provides both crash with non-Corba
exception. Restarting nameserv solves the problem.

Such situations were not noticed in Orbacus 4.2.1 and JDK1.4.2. 

Also in a few cases it was noticed exceptions in the code generated by jidl,
for instance:
     [java] java.lang.ArrayIndexOutOfBoundsException: -826472736
     [java]     at
com.packet411.framework.proxy.P_DiscoveryType.from_int(Unknown Source)
     [java]     at
com.packet411.framework.proxy.P_DiscoveryTypeHelper.read(Unknown Source)
     [java]     at
com.packet411.framework.proxy.P_DiscoveryEventHelper.read(Unknown Source)
     [java]     at
com.packet411.framework.proxy.P_GeminiEventHelper.read(Unknown Source)
     [java]     at
com.packet411.framework.proxy.P_ED4PPEPOA._OB_op_DispatchGeminiEvent(Unknown
Source)
     [java]     at com.packet411.framework.proxy.P_ED4PPEPOA._invoke(Unknown
Source)
     [java]     at
com.ooc.OBPortableServer.ServantDispatcher.dispatch(ServantDispatcher.java:2
14)
     [java]     at
com.ooc.OBPortableServer.POA_impl._OB_dispatch(POA_impl.java:1775)
     [java]     at
com.ooc.OB.DispatchRequest_impl.invoke(DispatchRequest_impl.java:52)
     [java]     at
com.ooc.OB.DispatchSameThread_impl.dispatch(DispatchStrategyFactory_impl.jav
a:46)
     [java]     at com.ooc.OB.Upcall.invoke(Upcall.java:434)
     [java]     at
com.ooc.OB.ThreadedGIOPConnectionHandler.doReceive(ThreadedGIOPConnectionHan
dler.java:500)
     [java]     at
com.ooc.OB.GIOPReceiverThread.run(ThreadedGIOPConnectionHandler.java:57)

Such exceptions also were not noticed in Orbacus 4.2.1 and JDK 1.4.2

I would very appreciate your advice concerning reliability of Orbacus 4.2.2
+ JDK 1.5 combination. 

Thanks!
Andrey.


_______________________________________________
OB-Users Mailing List - [email protected]
http://mail.ooc.nf.ca/mailman/listinfo/ob-users
Visit our support FAQ before you send a message.
http://www.orbacus.com/faq/support.html