incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <rick...@gmail.com>
Subject Message fragments
Date Mon, 22 Jan 2007 11:30:43 GMT
I'm trying to debug an interoperability problem that's got me a bit 
stumped at the moment.  When the failure occurs, the client (Yoko) has 
just sent a request message with a fairly large payload (7116) bytes.  
When it goes to read the response, it gets a SocketClosed exception.  
 From the Sun RI side, there is a single stack trace showing up in the 
log that suggests that the RI is processing a CloseConnection message.  
I've checked and double checked, and I'm fairly confident that the 
CloseConnection is not getting sent from the client. so I'm not sure 
where this would be coming from.  I suspect the RI ORB may have queued 
up the close itself in response to some other problem. 

The reverse case does work, and same request sent from the RI server is 
sent as a series of message fragments, with no fragment holding more 
than 1012 data bytes (give a total sent packet size of 1024 bytes, 
including the header).  This makes me suspect the test case is hitting 
some sort of message size limit, which is not reported well by the RI.  
According to my instrumentation, I've successfully sent requests as 
large as 6800 bytes without error, so I'm not completely certain about 
this. 

My first thought was to implement message fragments to see if this makes 
the problem go away.  Unfortunately,  the current structure for handling 
requests does not appear to support this well. A quick-and-dirty 
approach would be to take the already marshalled output buffer, and 
replace it with a single output buffer containing all of the message 
fragments.  These fragments would be sent all at one time, as if it was 
a single request.  Is this a legitimate thing to do, or are there return 
responses that might need to be processed between fragments?

Rick

Mime
View raw message