RE: bugs/problems with Orbacus 4.2.2

Hi Darren, 

Please find my comments below.

> -----Original Message-----
> From: Darren Middleman [mailto:[email protected]]
> Sent: Friday, April 15, 2005 5:22 PM
> To: Andrey Mikhalchuk
> Cc: [email protected]; 'Packet411 Corporation'
> Subject: Re: [OB-Users] bugs/problems with Orbacus 4.2.2
> 
> Hi Andrey,
> 
> Please see my comments inlined below:
> 
> > [...]
> >
> > 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?
> 
> JDK 1.5 is not officially supported for Orbacus 4.2.2.  The only
> officially
> supported JDKs for this release are 1.3 and 1.4.  That being said, we have
> been able to successfully build and run Orbacus 4.2.2 using JDK 1.5, as
> recently as this morning.  As I mentioned in my previous email, this is a

Right, we also had Orbacus 4.2.2 successfully compiled and running with JDK
1.5, but unfortunately with low reliability during runtime and number of
exceptions in some tests not shown in JDK 1.4.2.

> very common error that occurs in JDK 1.4 and 1.5 when the -Xbootclasspath
> is not used correctly when running an Orbacus application.  Can you send
> me the command you are using to start your application and the value
> contained in the CLASSPATH environment variable?
> 
> There is also an Orbacus demo that should display this same error if the
> -Xbootclasspath is not enabled.  Try running the demo ob/demo/pi (using
> the
> provided run script) to see if you are getting the same error.  By
> default,
> if you are using JDK 1.5, you should see the error.  You should then
> modify
> the line:
> 
>   if `$echo $java_version | grep '1\.4' > /dev/null`
> 
> in the run script (around line 54) to the following:
> 
>   if `$echo $java_version | grep '1\.[45]' > /dev/null`
> 
> This should enable the -Xbootclasspath option if the JDK version contains
> the string 1.4 or 1.5.  Now if you run the demo, the error should go away.

Ok, I see. Actually company management decided to switch back to 1.4.2, so
probably we would stay with older version, especially assuming JDK 1.5
officially is not supported for Orbacus. Recompilation got rid of those
startup exceptions and also we are not seeing any exceptions in the
jidl-generated code. So 1.4.2 works better for us, but I think we'll get
back to JDK 1.5 as soon as it will be supported by Orbacus. 

> > [...]
> >
> > 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)
> 
> I assume that since you are referring to the applications as nameserv and
> eventserv that these are the C++ executables and not the Java versions of
> the Name Service and Event Service.  Are you able to obtain core files

Right, we're using C++ versions.

> from
> these crashes?  If so, and you built Orbacus with debugging information
> enabled, you should be able to obtain a call stack trace using a debugger
> such as gdb.  I would be helpful if you could forward these along, as I am
> unable to duplicate the problems you are seeing on my end.
> 
> Note that you may need to run 'ulimit -c unlimited' to ensure that core
> files are generated when your nameserv or eventserv applications crash.

Ok, as soon as I get the core file I'll definitely send it to you. But after
switching to JDK 1.4.2 I didn't get any crashes of those services (even
those ones which happened without any load on them). I'll be monitoring the
situation with eventserv and nameserv and let you know the status whether it
is good or not.

Unfortunately our entire build environment is switched to JDK 1.4.2, so I
can't repeat those problems anymore.

> 
> > - 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
> 
> Are you providing any configuration options or policies to the event
> service?

Yes, here is the configuration I used. Currently I have commented those
lines out because it appeared that default configuration has lower event
loss then the configuration listed here

ooc.event.max_events=50
ooc.event.max_retries=50
ooc.event.retry_timeout=1000
ooc.event.retry_multiplier=2
ooc.event.request_timeout=20

> > - 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.
> 
> What is the exception message that you are seeing?  So far I have been
> unable to duplicate the problem here but I'll keep looking into this.  If
> you are able to obtain a stack trace from this type of crash (as described
> above) it might also help locate the problem.
> > 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(Unkno
> wn
> > 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.j
> av
> > a:46)
> >      [java]     at com.ooc.OB.Upcall.invoke(Upcall.java:434)
> >      [java]     at
> >
> com.ooc.OB.ThreadedGIOPConnectionHandler.doReceive(ThreadedGIOPConnectionH
> an
> > 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
> >
> 
> Is this the complete stack trace that occurs with this exception?  What
> code is being executed when this exception occurs?  It seems odd that this
> type of problem should occur from code generated by the IDL compiler.  I
> see that the first few items in the trace contain non-Orbacus code, can
> you
> provide the code that is being run in the methods 'from_int()' and
> 'read()'.

This issue is gone now with JDK 1.4.2. I'll send additional info about the
problem when we I get it again.

> I also just want to verify which platform you are running on.  I thought I
> saw an additional email from you which indicated you were using Solaris.
> Is this correct and which version are you running?

Right, Solrais 9 on dual-Opteron Sun.


Ok, seems like most of the issues are gone with the recompilation with JDK
1.4.2. Thank you for the information you provided - it helped a lot!

> Regards,
> Darren
> 
> --
> Darren Middleman, Software Engineer
> Team Orbacus - Your CORBA Source
> Email: mailto:[email protected]
> WWW: http://www.orbacus.com/

_______________________________________________
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