Yes, I think that is it. Basically, my webservice, which started out simple, turned out to be a nightmare simply because the webservice is oblivious to the client state (crashed, disconnected, connected). It just happily waits for a message to arrive and return it back to a client that may not be there. Hence, my solution was for the webservice to spawn a new thread at startup that publishes status messages to the queue every minute or so. These status message get returned to the client and when this happens, it reconnects to the webservice and the process starts all over again. So basically, there are 2 threads, one subscribed and the other publishing status messages.
You may be thinking that there is a possibility of lost messages when the client crashes in between status messages and a real message arrives in the queue. Well, the webservice only passes the real message back to the client when instructed to do so. When the webservice gets a real message, it will consume it, inspect it for certain conditions, and republish it back to the same queue. It will then return a status back to the client indicating that a message has arrived. The client, if it is there, will call the webservice again to get the message. If the client has crashed, well, the message is still in the queue and when the client comes back online, the first thing it does is get any outstanding messages. It is complicated, but it works. If you have any suggestions on how to get around this with a C# frontend and a java back end that communicates strictly through port 80 or 443, then please let me know!!! Anyway, I believe it is the thread that publishes the status messages that is causing the problem because I'm connecting with the same client name as the other thread that is subscribed to the queue. I will have to confirm this when I get the chance later on tonight. I will let you know. ----- Original Message ---- From: Marcel Ruff <[EMAIL PROTECTED]> To: [email protected] Sent: Tuesday, January 23, 2007 1:36:09 PM Subject: Re: [xmlblaster] Annoying Warning about recv failed If you use a positive session id like "client/joe/session/1" (or "joe/1") you MUST assure that only such client exists, if by mistake two of them get alive they will throw each other out of the server ... Could it be such a behaviour? regards Marcel chris lau wrote: > hmm... your points have me thinking Marcel. > > The chain is correct. The client only sends data to the web service. The data > determines what the webservice does. > It is the webservice that connects, publishes, retrieves and returns data to > the client. Messages are published in PTP mode. > > 1. I have will have to test. > 2. It is only the webservice that talks to the blaster server. Nobody else. > 3. This has me thinking that I forgot to close the connection to the server > before exiting? > > > ----- Original Message ---- > From: Marcel Ruff <[EMAIL PROTECTED]> > To: [email protected] > Sent: Tuesday, January 23, 2007 3:18:42 AM > Subject: Re: [xmlblaster] Annoying Warning about recv failed > > Hi Chris, > > i assume this chain: > > Client C# ----SOAP/SSL----> servlet : java xmlBlaster client > -----SOCKET---> xmlBlaster server > > Your problem is that the java client looses connection to the > server. > > The exception tells me that the SOCKET connection will be shutdown. > As your publish arrives there must be a reconnect behind the scene. > > I'm quite sure that your java xmlBlaster client has some coding problem > or it is another client showing the behaviour. > > 1. Try to test you client 'standalone' outside of tomcat > 2. Who does the reconnect after your lost connection? > 3. Can you switch on detailed logging inside tomcat showing the > xmlBlaster client lifecycle? > > thanks > Marcel > > > chris lau wrote: > >> Hi, >> >> Recently, I moved from a pure Java client to a C# .Net 1.1 client. This >> meant that I had to stop using the xmlblasterappletlib.jar servlet and write >> my own webservice. Everything is working fine except that I get these >> annoying java.net.socketexception warnings in the xmlBlaster server console. >> I don't know why I'm getting these warnings because it doesn't really effect >> the operation of the client or server (ie. no messages lost or anything). >> >> The message is: >> Jan 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 >> >> So everytime the client publishes a message to the server, I get the above >> warning on the console. The message reaches it's destination without any >> problems. >> >> Some other relevant details are: >> 1. Server machine is running Windows XP SP2. >> 2. Running Apache Tomcat 5.5.15 with a single webservice developed on >> Netbeans 5.5 >> 3. xmlBlaster 1.4 release. (no cvs versions). >> 4. webservice and xmlBlaster are on the same machine. >> 5. Client connects to webservice via SSL, but communication between >> webservice and xmlBlaster is not using SSL. Actually, I turned of the SSL >> between the client and webservice and I still get the same message. >> >> I don't know. I'm lost. Is it some property that I didn't configure properly >> or is it something in my code that I didn't do right? Or is it something to >> do with Tomcat? >> >> Any help would be appreciated. >> >> Chris. >> >> __________________________________________________ >> 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 > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
