[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xmlblaster] Annoying Warning about recv failed



Okay, thanks. It's no big deal if no messages are lost. The server is pretty slow since it is a PII 266mhz 192mb of RAM (test server) so I'm not surprised.


----- Original Message ----
From: Marcel Ruff <mr at marcelruff.info>
To: xmlblaster at server.xmlBlaster.org
Sent: Sunday, January 28, 2007 5:01:20 AM
Subject: Re: [xmlblaster] Annoying Warning about recv failed


The warning

an 21, 2007 4:29:29 PM WARNING 19-XmlBlaster.SOCKET RL10 org.xmlBlaster.protocol.socket.HandleClient run: Error parsing TCP data from '/192.168.1.102:4178', check if client and server have identical compression or SSL settings: java.net.socketException: Software caused connection abort: recv failed


is emitted when the socket handle throws an exception.
It could happen when the client closes the socket very quickly
before the server has processed a disconnect.

But it can also be a hint for a misbehaving client.
If you want to suppress it try the command line (or xmlBlaster.properties entry)

  -logging/org.xmlBlaster.protocol.socket.HandleClient SEVERE


Marcel

chris lau wrote:
> okay, I did some testing on my webservice. What I found out is really bizarre. Basically, I stripped the webservice down to a simple
> connect as in the following code:
>
> I_XmlBlasterAccess con = null;
> Global glob = null;         
>
> try {
>   glob = new Global();
>
>   con = glob.getXmlBlasterAccess();
>   
>   ConnectQos qos = new ConnectQos(glob);
>   qos.setSessionName(new SessionName(glob, "test_publisher"));
>
>   System.out.println ("Connecting");
>   con.connect(qos, null);
>
> } catch (XmlBlasterException e) {
> } finally {
>   System.out.println ("Disconnecting");
>
>   try { Thread.sleep(1000); } catch (InterruptedException e) {}
>
>   if (con != null) {
>     if (con.isConnected()) 
>        con.disconnect(new DisconnectQos(glob));
>   }
> }
>
> In the finally section, I upped the sleep time to 5000 instead of 1000 so I could tell when the disconnect would happen and when the recv-failed message appeared. It looks like the recv-failed message appears on disconnect. So to confirm this, I commented out the disconnect and the message doesn't appear after the client quits. I did this a few times to confirm.
>
> I then added another Thread.sleep command of 5 seconds right after the disconnect so I could confirm that it was the disconnect command causing this warning. After looking at the blaster console I was able to count 5 seconds, then the recv-failed message appears, then counted another 5 seconds, and my client program resumes from it's call to the webservice.
>
> Is there anyway I coded the disconnect call wrong?
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
>
>
>

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com