Leif, >I had been getting a series of occasional stack dumps from the altrmi >code when using it >to connect to an InstrumentManager from a client. I think that I got >them all worked out. > >1) There was a couple places where data was not being read fully: >ServerCustomStreamReadWriter.readRequest() >ClientCustomStreamReadWriter.readReply() > >Paul, could you take a look at these two changes and make sure that you >agree with them >I assume that some of the other transports may also have similar problems. > The changes look good and have not affected performance.
>2) Even after the above fixes, I was getting EOFExceptions once in a >while on the server >resulting in a stack dump. The stack dump was simply because the case >was not being >caught. It is not interpreted as the connection being closed. >StreamServerConnection.run() > IOException is a real pain when trying to handle both JDK 1.3 and 1.4 compatability. In 1.3 some EOF like exceptions are pushed via IOException ( not testable via instanceof, only getMessage().equals(..) ... sucks). The change looks good. >3) This last one took me a while. Why was the EOFException taking place. >It turns out >that the client was closing the connection. The connection was being >closed due to a >InterruptedIOException: Read timed out. This was caused because the >socket so timeout >was being set to 1 second. When the system was slow, the read would >sometimes take 1.1 >seconds or a little more, resulting in a timeout and disconnect. >I fixed this by changing the timeout to 60 seconds. I wanted to make >sure that there was >not a reason why this had been set to 1 second? Even at 1 minute, it >seems possible that >this could cause problems. Esp if the remote method takes some time to >execute. If it is >not needed, it might be best just to remove the timeout completely. >AbstractSocketStreamInvocationHandler.makeSocket() >Doing a search, there are 3 other places where a so timeout is being set >to 36 seconds. > There was a reason that I had set the tmeout to one second, but I cannot remember what it is now! I am sure if it was important that it will crop up again.... The related issue is that the system has to determine when there is a problem and resetablish a connection. Vinay is working on Callback which will have lots of benefits for us. Chiefly we will be able to post-request, wait for reply, get-reply instead of post-request-get-reply as at present. It means that the pinger will be able to intersperse pings() in possibly before a long reply has come back and confirm that waiting is worth it and the connection is not dead. When Vinay ships the code, we will prove it for Callback first, then merge it onto the core handlers. Unless there appears to be a large performance drop in which case we will allow the deployer to choose synchonous or asynchornous handlers.... >Anyway, give these changes a try and let me know if they caused any >problems. > They did not .... :-) - Paul -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
