[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xmlrpc-user
Subject:    Re: random connection refusal
From:       Andreas Schoelver <tengri_lethos () web ! de>
Date:       2005-08-27 19:22:57
Message-ID: 20050827212257.54095d6e.tengri_lethos () web ! de
[Download RAW message or body]

IMO it would be a good idea to have one client running.
If neccessary (depends on your business logic and response times),
the client could use one thread for each of the servers.
BTW: Did you mean client per server? Or what does client per host mean
in comparison to 'one static client'?

IMO: one client per host with one thread per server.

Don't know whether it makes sense in your application to keep the connections
open all the time, but that would avoid the problem of 'connection refused'
if the number of connections during a short period of time increases too much.

Starting a new client for each new transmission sounds similar to what
my test environment does - and this leads to 'connection refused'
situations under special circumstances.

If the overall number of required clients / connections is known and/or
static, it would be better to run the client(s) continuously.

I also noticed that 'java.util.NoSuchElementException' situation while
running my test client from a fast machine against a server on a 
slower machine - both using XML-RPC 2.0.

The server reported several exceptions long time before the first
client thread failed.

A mail from David Kastenholz (2005-07-27 on this list) contained 
a link with informations on how to increase the number of ports
available on windows.

Andreas

On Thu, 25 Aug 2005 16:44:52 -0600
"Mayer, Daniel S" <DSMayer@impactsci.com> wrote:

> 	Thanks that is helpful. 
> 	 
> 	I ran netstat -a to see how many were in the wait state and there seem to be \
> tons... like a hundred in the wait state. Still almost all of my requests are \
> handled just a few missing here and there. I was thinking all of these in the \
> waiting state might be kept open after I have a client execute a request and return \
> a result.  
> 	Do I have to do anything on either the client side or server side to say after I \
> return close that socket I am done with it. I know that these sockets are \
> eventually closing from some time out because after I have closed all my programs \
> for awhile they all still show up in netstat with hundreds waiting and then all \
> disappear pretty much at once a few minutes after I closed everything.  
> 	Or does this mean I am using the client wrong, by creating a new client and \
> executing on it each time I want to send / receive a result. Do I need to set up a \
> dispatcher or something and only use one static client the whole time? I am talking \
> to multiple hosts so would it be best to have one client per host?  
> 	I added keepAlive(true) to both servers and clients, which seemed to help a lot \
> and really reduce how many were waiting all but eliminated from the local \
> connections, but there are still many many sockets from remote hosts in the wait \
> state, when it should really only have one or two connections going from each \
> server at a time. It seems that eventually my messages never go through after I \
> build up a ton of messages in the wait state (which happens when I am running 4 \
> remote clients communicating with 2 threads all the time with the server.  This \
> does lead to a bug that someone has placed on the list or mentioned before where \
> the server keeps printing out java.util.NoSuchElementException, which doesn't seem \
> to cause an error in execution, but keeps being printed out with no other trace.  
> 	When I was working with asynchronous awhile ago I ran into another similar \
> reported error that even had a patch suggested for the fix, but didn't have the \
> patch applied in the binary release which seems outdated, so I had to get the code \
> from CVS and apply the patch myself.   
> 	I am scared to ask but after going through the bug tracking for this project \
> (http://issues.apache.org/jira/browse/XMLRPC) , there seems to be many unresolved \
> bugs, some of which have solutions or patches on the web, but don't seem to be \
> resolved on the tracking system. So is the development of this project still \
> active? Is it safe to rely on XML RPC for software that should run 24/7 with a \
> reboot about once every 2 weeks? Has everyone doing this sort of thing moved to \
> soap and JAX-rpc? The amount of open bug fixes has just made me a little nervous, \
> and I haven't been following xml-rpc very long. The user list still seems to be \
> very active, but is the development? Anyways thanks for your time, help, concern... \
>   Peace,
> 	Dan "I am nervous, I guess I should dance to some techno to relax" Man
> 	 


[prev in list] [next in list] [prev in thread] [next in thread]