Re: OB 4.20 sp2 -> Java 5.0: pb with callbacks

Hi Fabrice,

On Fri, Jun 17, 2005 at 01:13:40PM +1100, Fabrice Bouye wrote:
> For our project we are using a C++ server with ORBacus 4.20 sp2 and Java 
> 5.0 clients using Sun's ORB that are talking to each other. The server 
> monitors an oceanographic data simulator that holds data to be represented 
> as bitmaps on the clients. So far when clients connect to the server and 
> download data all work OK. But we need to use a callback function so the 
> server tells the clients the simulator has achieved a new run; that ways the 
> client will re-download the necessary data and update the display. 
>  
> In addSeapodymRCListener() when the server call listener->getName(), it 
> works OK and prints the name provided by the client. But each time 
> fireNewRunStarted() is called it crashes with UNKNOW ERROR when 
> it->second->newRunStarted(runNumber) is called.
> As of now the Java client-side of newRunStarted() simply does a 
> System.out.println("New run detected" + runNumber) for debugging.
> The POA has been correctly activated prior to the ORB start in the server's 
> initialization process.
>  
> I suppose that the reference pointer to the listener may get released when 
> exiting addSeapodymRCListener(), and this causes the reference to be invalid 
> in fireNewRunStarted() but I'm puzzled as I cannot detect if there is any 
> error in the way I store/cache the listener. 
>  
> Thanks for your help.

In Orbacus there are two base exception classes that you may want to
catch in this case.  The first is CORBA::Exception which is the base for
all CORBA System and User exceptions.  The second is the JTCException
class which is the base exception class for the Orbacus cross-platform,
Java-like threading library.  I would try to catch both of these just in
case (I can see you are already catching CORBA::Exception so you really
only need to add a catch for JTCException).

If neither of these exceptions are caught (meaning it falls through to
the catch(...)), then I would set a breakpoint inside the catch(...) and
try to obtain a stack trace.  Alternatively you can let the debugger
break whenever an exception is thrown and see if you can determine the
root.  Once you have the source of the exception I can help you futher
determine the cause of the problem.  

Cheers.

-- 
Dion Picco, Software Engineer
IONA Technologies Inc.
Team Orbacus - Your CORBA Source
mailto:[email protected]
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