EVALUATION
The problem is around code set negotiation b/w client and server.
From problem configuration: We have studied the GIOP dumps from the server
side and noted that when the problem (failure of RMI on subsequent calls after
restart of the server) happens, there is no codeset info. in the client request.
It appears from the GIOP dumps that the client sends the codeset info only
during *first* contact by client to server after server restart. But,
since the client had a stale IOR, the client's request does not really get
past reading the codeset info. Seems like client's thinking is that it
already sent the codeset info, hence will not send it again, unless a new
connection is created.
Ideally, for the problem scenario, upon first contact, client opens a new
connection and set the codeset cache to null. Since the first request, after
creating a new connection, fails because of the stale IOR that client has,
the codeset cache should be still be null, which indicates the client, to
send the codeset info. in the next request. But, that's not happening during
the problem time, when the JSP client from weblogic trying to make RMI on the
remote object. Client does not re-send the codeset info as per GIOP spec
section 13.10.2.6 (most commonly)
The fix is, to consume code set information first, before bailing out with an
exception, as client may not resend those bytes!
###@###.### 2005-07-19 18:36:41 GMT
|
Java