[jacorb-bugs] [Bug 915] Bugs in calling PERSISTENT corba server methods

[bugzilla-daemon at jacorb.org]

http://www.jacorb.org/cgi-bin/bugzilla/show_bug.cgi?id=915


mesnier_p at ociweb.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED




------- Comment #2 from mesnier_p at ociweb.com  2012-01-19 16:29 -------
Here's what is happening to cause this problem.

The client is firing off 100 concurrent requests, one per thread. 

Several of these go off to the IMR, which dutifully sends back location
forwarding details. 

The Delegate processes the location forward, rebinding and "resetting" all
waiting requests, because these must all be waiting on the IMR, right?
Unfortunately in this case, this is not right.

Upon receiving the first location forward, the Delegate rebinds, which releases
the connection to the IMR and opens a new connection to the server. Since there
were several requests sent to the IMR, multiple location forward exceptions are
received from the IMR before the connection is released, and each one triggers
a reset/rebind. 

Since the machine is loaded, it takes time to actually spawn all 100 threads,
meaning some requests are started after the first rebind occurred, meaning the
client sent the request to the real server.  When the second rebind occurs, all
of these threads dutifully stop waiting and remarshal and resend. Depending on
the system load, this can happen several times, leading to 3 or more
duplications of a request. This effect can impact many threads, leading to
dozens of duplicated requests sent to the server.

Now for the solution. The easiest fix is to do nothing to JacORB, and
restructure the client application so that a connection to the real server is
established prior to starting any MT activity. However this breaks down if for
instance the client doesn't obtain the target IOR until it has already entered
its MT operational phase, or if perhaps the connection to the server is lost
and must be reestablished.

I think the durable solution is to be more intelligent about when to abandon a
request. This would involve modifying the ReplyReceiver and the Delegate so
that the RR can decide if it truly needs to abandon the current request or not.


-- 
Configure bugmail: http://www.jacorb.org/cgi-bin/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.