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 <mr at marcelruff.info>
To: xmlblaster at server.xmlBlaster.org
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 <mr at marcelruff.info>
To: xmlblaster at server.xmlBlaster.org
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