[jacorb-developer] Client-to-ImR Connection Thrashing

Steve Osselton steve.osselton at prismtech.com
Wed Jul 25 10:47:26 CEST 2012


Hi Mike,

I think the behaviour you are seeing is correct. You might want to use IMR
functionality to implement something such
as load balancing where you have multiple servers that can implement an
interface, and each request is send to
a new server using some sort of IMR policy (such as round robin). The IMR
lookup is directly related to the lifetime
of the object reference, so between the initial call and release, only a
single call will be made to the IMR (to resolve the server).
To reduce calls to the IMR, you need to somehow cache the object reference
between calls, so you are making calls on the
same object reference.

Cheers Steve.

On 25 July 2012 01:13, McKnerney, Michael D (US SSA) <
michael.mcknerney at baesystems.com> wrote:

> Hi Nick (and anybody else who might comment)
>
> Here's what I am seeing when I talk about connection thrashing for ImR
> references:
>
> 1:            String iorString = // ImR reference
>
> 2:            org.omg.CORBA.Object obj =  orb.string_to_object(iorString);
> 3:            SomeIf demo = SomeIfHelper.narrow( obj );
> 4:            demo.op();
>
> 5:            org.omg.CORBA.Object obj2 =  orb.string_to_object(iorString);
> 6:            SomeIf demo2 = SomeIfHelper.narrow( obj2 );
> 7:            demo2.op();
>
> 8:            demo2._release ();
>
>
> Line (4)
>    - opens a new connection with the ImR
>    - closes connection with the ImR
>    - opens a new connection with the [newly started] impl server
>    - connection to impl server stays open
>
> Line (7)
>    - opens a new connection with the ImR
>    - closes connection with the ImR
>    - reuses existing connection with the impl server
>    - connection to impl server stays open
>
> Line (8) -- I think this line is optional, i.e., just let the object go
> out-of-scope ?
>    - cannot release ClientGIOPConnection to 10.35.225.150:59149 (13adc56)
> (still has 1 client(s)))
>
> So the connection thrashing I'm talking about is the fact that EVERY Imr
> reference (even if its logically the same) ALWAYS opens and closes a
> connection with the ImR.
>
> Just want to confirm what I'm seeing is true.
>
> Thanks again for the help !
> -mike
>
> -----Original Message-----
> From: Nick Cross [mailto:jacorb at goots.org]
> Sent: Tuesday, July 24, 2012 6:05 AM
> To: McKnerney, Michael D (US SSA)
> Subject: Re: Client-to-ImR Connection Thrashing
>
>
> Hi Mike,
>
> I have had a quick look at this -
>
>
> diff -b -B -w ~/Downloads/imrThrashing/src/demo/imr/Client.java
> src/demo/imr/Client.java                           13:56
> 63,68c63
> < while (true) {
> < System.out.println("press a key");
> < try { System.in.read(); } catch (Exception e2) {}
> <
> <             org.omg.CORBA.Object obj2 =
> <                 orb.string_to_object(iorString);
> ---
>  >             org.omg.CORBA.Object obj2 = orb.string_to_object(iorString);
> 72a68,72
>  >             while (true)
>  >             {
>  >                 System.out.println("press a key");
>  >                 try { System.in.read(); } catch (Exception e2) {}
>  >
>
> I tried changing the code as per above so the client delegate object
> (which will open up the connection) is created outside of the loop.
>
> As a further test I tried manually releasing the resources (and therebye
> the connection):
>
>              System.out.println("Client: successfully called server");
>
>              org.omg.CORBA.Object obj2 = orb.string_to_object(iorString);
>
>              //narrow to correct interface
>              SomeIf demo2 = SomeIfHelper.narrow( obj2 );
>
>              while (i++<10)
>              {
>                  System.out.println("press a key");
>                  try { System.in.read(); } catch (Exception e2) {}
>
>                  //call remote op
>                  System.out.println("Client: will call server");
>                  demo2.op();
>                  System.out.println("Client: successfully called server");
>              }
>              System.out.println("Client: releasing...");
>              demo2._release ();
>              obj2._release ();
>
>              obj2 = orb.string_to_object(iorString);
>              demo2 = SomeIfHelper.narrow( obj2 );
>              demo2.op();
> and this creates another connection.
>
> Could you try this?
>
> Cheers
>
> Nick
>
>
>
> On 24/07/12 00:54, McKnerney, Michael D (US SSA) wrote:
> > Hi Nick,
> >
> > Hope you had a nice vacation with your family !
> >
> > I've attached imrThrashing.jar and jacorb.properties if you have time to
> have a look.
> >
> > Basically, the same as the original demo/imr with slight modification to
> Client.java.
> >
> > All I changed in Client.java was a loop that uses obj2 for a very short
> period.  It's like our real application except that we don't read ior from
> file but rather from NameService and the lifetime of the reference is very
> short.
> >
> > Build:
> >> cd ${JACORB_HOME}
> >> mkdir imrThrashing
> >> cp ~/imrThrashing.jar .
> >> jar xvf imrThrashing.jar
> >> ant compile
> >
> > Register:
> >> imr_mg add imr_demo -h mcknerney2-lnx5-dev -c "xterm -title
> IMR_DemoServer -ls -sb -sl 5000 -e jaco -cp
> ${JACORB_HOME}/demo/imrThrashing/build/classes:${JACORB_HOME}
> demo.imr.Server ${JACORB_HOME}/demo/imrThrashing/IOR 60"
> >
> > Run Server 1st time to create IOR
> >> cd ${JACORB_HOME}/demo/imrThrashing
> >> jaco -cp ${JACORB_HOME}/demo/imrThrashing/build/classes:${JACORB_HOME}
> demo.imr.Server ${JACORB_HOME}/demo/imrThrashing/IOR 60
> >
> > Run client
> >> cd ${JACORB_HOME}/demo/imrThrashing
> >> jaco -cp
> ${JACORB_HOME}/demo/imrThrashing/build/classes:$JACORB_CLASSPATH
> demo.imr.Client ${JACORB_HOME}/demo/imrThrashing/IOR
> >
> > You'll see that a new connection is created on each cycle through the
> loop.
> >
> > Client log:
> > ----------------
> > DEBUG | ConnectionBase.java      :149  | 2012-07-23 23:40:32,825 |
> ConnectionBase           | to_COMM_FAILURE          |
> tid:ClientMessageReceptor0 | to_COMM_FAILURE: Caught exception
> > java.net.SocketException: Socket closed
> >          at java.net.SocketInputStream.socketRead0(Native Method)
> >          at java.net.SocketInputStream.read(SocketInputStream.java:129)
> >          at
> org.jacorb.orb.etf.StreamConnectionBase.read(StreamConnectionBase.java:111)
> >          at
> org.jacorb.orb.giop.GIOPConnection.getMessage(GIOPConnection.java:381)
> >          at
> org.jacorb.orb.giop.GIOPConnection.receiveMessagesLoop(GIOPConnection.java:539)
> >          at
> org.jacorb.orb.giop.GIOPConnection.receiveMessages(GIOPConnection.java:528)
> >          at
> org.jacorb.orb.giop.MessageReceptor.doWork(MessageReceptor.java:70)
> >          at
> org.jacorb.util.threadpool.ConsumerTie.run(ConsumerTie.java:61)
> >          at java.lang.Thread.run(Thread.java:662)
> > DEBUG | GIOPConnection.java      :395  | 2012-07-23 23:40:32,826 |
> GIOPConnection           | getMessage               |
> tid:ClientMessageReceptor0 | ClientGIOPConnection to 10.35.225.150:59676(1ebd75b): getMessage() -- COMM_FAILURE
> >
> >
> > ImR log:
> > -------------
> > DEBUG | StreamConnectionBase.java:146  | 2012-07-23 23:40:32,825 |
> StreamConnectionBase     | read                     |
> tid:ImplementationRepository0 | Transport to 10.35.225.150:51491: stream
> closed on read  < 0
> > DEBUG | GIOPConnection.java      :395  | 2012-07-23 23:40:32,825 |
> GIOPConnection           | getMessage               |
> tid:ImplementationRepository0 | ServerGIOPConnection to
> 10.35.225.150:51491 from [10.35.225.150:43347] (16c9867): getMessage() --
> COMM_FAILURE
> >
> >
> >> netstat -ap |grep 59676    // jacorb.imr.endpoint_port_number=59676
> >
> > tcp        0      0 mcknerney2-lnx5-dev.i:59676 *:*
>     LISTEN      13158/java
> > tcp        0      0 mcknerney2-lnx5-dev.i:50417
> mcknerney2-lnx5-dev.i:59676 TIME_WAIT   -
> > tcp        0      0 mcknerney2-lnx5-dev.i:50416
> mcknerney2-lnx5-dev.i:59676 TIME_WAIT   -
> > tcp        0      0 mcknerney2-lnx5-dev.i:50419
> mcknerney2-lnx5-dev.i:59676 TIME_WAIT   -
> > tcp        0      0 mcknerney2-lnx5-dev.i:50418
> mcknerney2-lnx5-dev.i:59676 TIME_WAIT   -
> > tcp        0      0 mcknerney2-lnx5-dev.i:50420
> mcknerney2-lnx5-dev.i:59676 TIME_WAIT   -
> > tcp        0      0 mcknerney2-lnx5-dev.i:50410
> mcknerney2-lnx5-dev.i:59676 TIME_WAIT   -
> > tcp        0      0 mcknerney2-lnx5-dev.i:50415
> mcknerney2-lnx5-dev.i:59676 TIME_WAIT   -
> >
> >
> > Btw- I tried setting this property to "on" but it had no affect
> >
> > jacorb.reference_caching=on
> >
> > And I could not find any documentation on this property.
> >
> > Is it used to avoid unnecessary binding and, if so, why not 'on' by
> default ?
> >
> > Thanks for having a look if you have time
> > Take care,
> > Mike
> > P.S  I still need to get that test case for PortableInterceptor to you
> but I'm on the hook to finish this porting task first :-)
> > I don't see any existing junit test cases for jacorb to model mine
> after, are there some ?
> >
> >
> > -----Original Message-----
> > From: McKnerney, Michael D (US SSA)
> > Sent: Monday, July 23, 2012 3:47 PM
> > To: Discussions concerning CORBA development with JacORB
> > Subject: Client-to-ImR Connection Thrashing
> >
> > Hi,
> >
> > Our usage of ImR reference is causing a new connection to be established
> between client and ImR on EVERY invocation on the reference.  May be
> related to the lifetime of the reference scope, not sure ?
> >
> > Obviously, we want the connection from the client-to-ImR to happen only
> once and then stay open indefinitely.
> >
> > I'll send an ImR demo that shows the issue.
> >
> > Thanks for helping me figure out what's going on
> > -mike
> >
>
>
> _______________________________________________
> jacorb-developer maillist  -
> jacorb-developer at lists.spline.inf.fu-berlin.de
> https://lists.spline.inf.fu-berlin.de/mailman/listinfo/jacorb-developer
>



-- 
CORBA/Software Defined Radio Delivery Manager
PrismTech Chief Architect

e-mail:  steve.osselton at prismtech.com
tele     +44-191-497-9905
web:     www.prismtech.com

PrismTech is a global leader in standards-based, performance-critical
middleware.  Our products enable our OEM, Systems Integrator, and
End User customers to build and optimize high-performance systems
primarily for Mil/Aero, Communications, Industrial, and Financial Markets.


More information about the jacorb-developer mailing list