Multithreading and Blocking of Deployed Services

[Alex Rau <ra...@gmx.de>]

Hi there,

for a student job we're developing a newsgroup system for mobile devices 
(Compaq Ipaqs).

Currently, we have some trouble with the deployed service class. On 
desktop computers everything works fine, but the slow ipaqs showed up 
some strange deadlock problem, which hasn't been detected before.

Each ipaq owns a server thread and a client thread. The server thread 
offers the deployed service interface (methods mainly for requesting 
messageids and messages) and the client thread is looking for new 
servers and downloading messages on detection. On detection of another 
ipaq in the wlan, both try to send a soap request to the other one's 
server, which should return a vector with message ids or just messages, 
which are available for download.

When a server thread receives a soap request from a client, it first has 
to call private methods in its own interface via soap for calculating 
the results. This does not work, because the first soap request (from 
the client) has not been finished and no soap response has been sent 
back, so the interface class blocks method invokation (second internal 
soap request) until the first (client) soap request has really finished. 
That's why the client soap request result blocks forever -> deadlock.

So the problem seems to be, that apache soap can't handle soap requests 
in parallel. My question is now: is this assumption correct or did we 
make any errors ? Is it in general impossible in java, to call two 
(different) methods on the same object from two threads ? I don't think 
so, but u never know :S

Note:
- It's not possible to slice the service interface into several classes 
for multithreading, because data between more than one interface can't 
be shared (at least i do not know, how this should be done, because 
several deployed interfaces have no references to each other).

- There're no synchronized blocks in the service interface (neither in 
the whole implementation), which could explain the blocking behaviour.

Regards,
 Alexander Rau

Re: Multithreading and Blocking of Deployed Services

[Alex Rau <ra...@gmx.de>]

Hi Jason,

we did a major code rewrite last night. Mainly we moved the gui and 
broadcast stuff into the service class. This way we saved a lot of soap 
requests. Another issue was our servlet container, which we manipulated 
for debugging purposes and started to fail to server multiple requests 
in parallel.

After this code rewrite our system worked without deadlocks. Today we 
ran it on 2 ipaqs and one notebook and tested our first information 
dissemination algorithms :)

When i said, the service interface would call it self via soap, i did a 
mistake. It was calling the other clients service interface. But the 
idea of writing a complete web application instead of simple service 
interface and a "normal" application holding the servlet container did 
help (reduced bandwidth and error detection :) ).

Tnx a lot,

Regards Alexander Rau

PS: Anyone offering an intership for a computer science graduate student 
from germany for about 3-6 (or even more) months in the sf bay area ?

Re: Multithreading and Blocking of Deployed Services

[Alex Rau <ra...@gmx.de>]

Hi Jason,

we did a major code rewrite last night. Mainly we moved the gui and 
broadcast stuff into the service class. This way we saved a lot of soap 
requests. Another issue was our servlet container, which we manipulated 
for debugging purposes and started to fail to server multiple requests 
in parallel.

After this code rewrite our system worked without deadlocks. Today we 
ran it on 2 ipaqs and one notebook and tested our first information 
dissemination algorithms :)

When i said, the service interface would call it self via soap, i did a 
mistake. It was calling the other clients service interface. But the 
idea of writing a complete web application instead of simple service 
interface and a "normal" application holding the servlet container did 
help (reduced bandwidth and error detection :) ).

Tnx a lot,

Regards Alexander Rau

PS: Anyone offering an intership for a computer science graduate student 
from germany for about 3-6 (or even more) months in the sf bay area ?

RE: Multithreading and Blocking of Deployed Services

[Jason Smith <js...@fugen.com>]

> On
> desktop computers everything works fine, but the slow ipaqs showed up
> some strange deadlock problem, which hasn't been detected before.
	This tells me you need to check your JVM on the iPaq and see how it handles
things like threads.

> When a server thread receives a soap request from a client, it first has
> to call private methods in its own interface via soap for calculating
> the results.
	This doesn't make much sense to me.  If a server has received a request why
does it have to invoke methods on itself via SOAP unless it was to a
different SOAP service?  If you are in one "service" or Java object just
invoke the method because you're already in the object, right?


 This does not work, because the first soap request (from
> the client) has not been finished and no soap response has been sent
> back, so the interface class blocks method invokation (second internal
> soap request) until the first (client) soap request has really finished.
> That's why the client soap request result blocks forever -> deadlock.
	This works in my desktop environment (JDK 1.3.1, Win 2000, Apache SOAP
v2.2).  I can call out to other soap services and I can invoke the same
service from within a service via SOAP (not that I would ever want to).
Again, this tells me you need to look at the JVM you are using and see if
there are known threading issues.  Why would the interface class block
additional invocations unless you were trying to synchronize?

> So the problem seems to be, that apache soap can't handle soap requests
> in parallel. My question is now: is this assumption correct or did we
> make any errors ?
	You said it worked on your desktop, and it worked on my desktop.  Bytecode
is the same right, so it does work...just apparently not on the iPaq.  I
would check for issues with your JVM and make sure you really want to
self-invoke via SOAP.

> Is it in general impossible in java, to call two
> (different) methods on the same object from two threads ? I don't think
> so, but u never know :S
	Sure you can, just watch out for synchronization issues (same as in any
threaded environment).  If your service is using collections of some sort
for data storage make sure you aren't doing anything funny by going through
"hidden" synchronized accessors to your containers.

> Note:
> - It's not possible to slice the service interface into several classes
> for multithreading, because data between more than one interface can't
> be shared (at least i do not know, how this should be done, because
> several deployed interfaces have no references to each other).
	I think this depends on your web container.  SOAP acts like a web
application, right?  So depending on how your deployment environment handles
things like scalability/failover and how many JVMs actually run it you might
be able to use some sort of Singleton/Factory patterns.  Have you considered
using session techniques for storing shared information?  This is probably
the preferred way.

Forgive me if I misinterpreted what you were trying to say, these are just
the first things that popped in my head.

-jason

RE: Multithreading and Blocking of Deployed Services

[Jason Smith <js...@fugen.com>]

> On
> desktop computers everything works fine, but the slow ipaqs showed up
> some strange deadlock problem, which hasn't been detected before.
	This tells me you need to check your JVM on the iPaq and see how it handles
things like threads.

> When a server thread receives a soap request from a client, it first has
> to call private methods in its own interface via soap for calculating
> the results.
	This doesn't make much sense to me.  If a server has received a request why
does it have to invoke methods on itself via SOAP unless it was to a
different SOAP service?  If you are in one "service" or Java object just
invoke the method because you're already in the object, right?


 This does not work, because the first soap request (from
> the client) has not been finished and no soap response has been sent
> back, so the interface class blocks method invokation (second internal
> soap request) until the first (client) soap request has really finished.
> That's why the client soap request result blocks forever -> deadlock.
	This works in my desktop environment (JDK 1.3.1, Win 2000, Apache SOAP
v2.2).  I can call out to other soap services and I can invoke the same
service from within a service via SOAP (not that I would ever want to).
Again, this tells me you need to look at the JVM you are using and see if
there are known threading issues.  Why would the interface class block
additional invocations unless you were trying to synchronize?

> So the problem seems to be, that apache soap can't handle soap requests
> in parallel. My question is now: is this assumption correct or did we
> make any errors ?
	You said it worked on your desktop, and it worked on my desktop.  Bytecode
is the same right, so it does work...just apparently not on the iPaq.  I
would check for issues with your JVM and make sure you really want to
self-invoke via SOAP.

> Is it in general impossible in java, to call two
> (different) methods on the same object from two threads ? I don't think
> so, but u never know :S
	Sure you can, just watch out for synchronization issues (same as in any
threaded environment).  If your service is using collections of some sort
for data storage make sure you aren't doing anything funny by going through
"hidden" synchronized accessors to your containers.

> Note:
> - It's not possible to slice the service interface into several classes
> for multithreading, because data between more than one interface can't
> be shared (at least i do not know, how this should be done, because
> several deployed interfaces have no references to each other).
	I think this depends on your web container.  SOAP acts like a web
application, right?  So depending on how your deployment environment handles
things like scalability/failover and how many JVMs actually run it you might
be able to use some sort of Singleton/Factory patterns.  Have you considered
using session techniques for storing shared information?  This is probably
the preferred way.

Forgive me if I misinterpreted what you were trying to say, these are just
the first things that popped in my head.

-jason