You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@ws.apache.org by John Luxford <lu...@simian.ca> on 2005/10/12 18:18:52 UTC

Re: WebServer class, threads/processes

Hi folks,

I posted this question a few weeks ago and didn't see any response to  
it, so I thought I'd try again.  If there's any additional info I can  
provide that would help, please let me know.

Thanks in advance,

Lux

On 23-Sep-05, at 9:39 AM, John Luxford wrote:

> Hi everyone,
>
> I've got an application using the org.apache.xmlrpc.WebServer class  
> and I've noticed that on most machines we run it on it is contained  
> to a single system process and presumably uses threads to divvy out  
> requests to.  On one machine however, starting the same app running  
> suddenly creates a dozen processes instead of just one, which would  
> lead me to believe it's creating new processes instead of threads  
> on that machine.
>
> Is this the case, and if so, is there any way to force it to use a  
> single process?
>
> Thanks in advance,
>
> Lux
>


Re: WebServer class, threads/processes

Posted by John Luxford <lu...@simian.ca>.
Hi Adam,

That makes sense.  I'll see what I can find out about the JVM on our  
one system.

I do have another strange occurrence on another newer server which is  
happening to our XMLRPC daemon.  Hopefully it's more relevant to this  
list.
Our new server is a Fedora Core 2 machine running the Java Hotspot VM  
version 1.5.0_04.  What's happening is that our XMLRPC daemon which  
uses the WebServer class is running fine for a while then suddenly  
stops accepting new connections.  It's still running, but no longer  
responding to requests.

I've checked that it's not resulting from an infinite loop in one of  
the methods that's being called, and it doesn't seem to be, and this  
problem is new to us since switching to the new server.

My other main test machine is an OSX 10.4 desktop with Java 1.4.2_09,  
and I haven't been able to reproduce the issue here.  We also have  
other clients using Java 1.3 through 1.5 elsewhere without issues.

Thanks again,

Lux

--

John Luxford
President and Chief Developer
______________________________
Simian Systems Inc.
Evolve Your Business
______________________________
web   : http://www.simian.ca/
email : lux@simian.ca
phone : 250.714.0440


On 12-Oct-05, at 12:22 PM, Adam Taft wrote:

> John,
>
> It might have something to do with either a) your JVM or b) the  
> operating system on the machine in question, or possibly the  
> combination of the two.
>
> I'd just check to make sure you've got a good JVM installed, the  
> latest version, etc.  I'm not aware of any command line switches or  
> anything to the JVM which, for example, forces it to use threads  
> instead of seperate processes.
>
> Your question was probably not answered on this mailing list mostly  
> because it sounds more like a JVM related question, not an XMLRPC  
> library related question.
>
> As far as the WebServer class, it only uses threads for connection  
> requests.  There's no choices otherwise, at least that I'm aware  
> of. The point is though, that the JVM is likely turning these  
> threads into separate processes, maybe because of lack of threading  
> support in the operating system kernel itself.
>
> Adam
>
>
> John Luxford wrote:
>
>> Hi folks,
>> I posted this question a few weeks ago and didn't see any response  
>> to  it, so I thought I'd try again.  If there's any additional  
>> info I can  provide that would help, please let me know.
>> Thanks in advance,
>> Lux
>> On 23-Sep-05, at 9:39 AM, John Luxford wrote:
>>
>>> Hi everyone,
>>>
>>> I've got an application using the org.apache.xmlrpc.WebServer  
>>> class  and I've noticed that on most machines we run it on it is  
>>> contained  to a single system process and presumably uses threads  
>>> to divvy out  requests to.  On one machine however, starting the  
>>> same app running  suddenly creates a dozen processes instead of  
>>> just one, which would  lead me to believe it's creating new  
>>> processes instead of threads  on that machine.
>>>
>>> Is this the case, and if so, is there any way to force it to use  
>>> a  single process?
>>>
>>> Thanks in advance,
>>>
>>> Lux
>>>
>


Re: WebServer class, threads/processes

Posted by Adam Taft <ad...@hydroblaster.com>.
John,

It might have something to do with either a) your JVM or b) the 
operating system on the machine in question, or possibly the combination 
of the two.

I'd just check to make sure you've got a good JVM installed, the latest 
version, etc.  I'm not aware of any command line switches or anything to 
the JVM which, for example, forces it to use threads instead of seperate 
processes.

Your question was probably not answered on this mailing list mostly 
because it sounds more like a JVM related question, not an XMLRPC 
library related question.

As far as the WebServer class, it only uses threads for connection 
requests.  There's no choices otherwise, at least that I'm aware of. 
The point is though, that the JVM is likely turning these threads into 
separate processes, maybe because of lack of threading support in the 
operating system kernel itself.

Adam


John Luxford wrote:
> Hi folks,
> 
> I posted this question a few weeks ago and didn't see any response to  
> it, so I thought I'd try again.  If there's any additional info I can  
> provide that would help, please let me know.
> 
> Thanks in advance,
> 
> Lux
> 
> On 23-Sep-05, at 9:39 AM, John Luxford wrote:
> 
>> Hi everyone,
>>
>> I've got an application using the org.apache.xmlrpc.WebServer class  
>> and I've noticed that on most machines we run it on it is contained  
>> to a single system process and presumably uses threads to divvy out  
>> requests to.  On one machine however, starting the same app running  
>> suddenly creates a dozen processes instead of just one, which would  
>> lead me to believe it's creating new processes instead of threads  on 
>> that machine.
>>
>> Is this the case, and if so, is there any way to force it to use a  
>> single process?
>>
>> Thanks in advance,
>>
>> Lux
>>
>