Create new thread from Web Service

[ShaneLM]

Hi, I'm new to java web services and am trying to understand the
context in which they are run. Any pointers to the web service
lifecycle (specifically through Axis2) would be awesome.

My specific problem is that I'm trying to create a web service that
spawns a background process that will keep running after the web
service call completes. So far my research has given 2 possible
methods.

1) Create a new thread during the service call. My worries are that
this will get killed as soon as the web service returns, or that I
won't be able to maintain a handle on it when I want to kill the
thread later.

2) Use the Axis2 framework to develop an asynchronous service, as
described here http://www.ibm.com/developerworks/webservices/library/ws-axis2/

Would these methods work? Which would you recommend?

In either method, what's the best way to exchange data between this
background process and any future web service calls?

Thanks so much for your time!
Shane

 

[Arne Vajhøj]

Hi, I'm new to java web services and am trying to understand the
context in which they are run. Any pointers to the web service
lifecycle (specifically through Axis2) would be awesome.

My specific problem is that I'm trying to create a web service that
spawns a background process that will keep running after the web
service call completes. So far my research has given 2 possible
methods.

1) Create a new thread during the service call. My worries are that
this will get killed as soon as the web service returns, or that I
won't be able to maintain a handle on it when I want to kill the
thread later.

2) Use the Axis2 framework to develop an asynchronous service, as
described here http://www.ibm.com/developerworks/webservices/library/ws-axis2/

Would these methods work? Which would you recommend?

In either method, what's the best way to exchange data between this
background process and any future web service calls?

I don't know those features of Axis2. The first two are client side
and not relevant for your question. The third could be a solution
for you.

If you start a thread, then the thread will not be stopped when
the call returns and you will be able to get the data via some
global data structure - like a singleton.

But in general it is bad practice to start threads inside the
web container. The may sys admin have spend time tuning the
number of threads in the container.

The true Java EE way is to have the call put the job in a message
queue and have a MDB do the processing.

Arne

 

[Daniel Pitts]

Hi, I'm new to java web services and am trying to understand the
context in which they are run. Any pointers to the web service
lifecycle (specifically through Axis2) would be awesome.

My specific problem is that I'm trying to create a web service that
spawns a background process that will keep running after the web
service call completes. So far my research has given 2 possible
methods.

1) Create a new thread during the service call. My worries are that
this will get killed as soon as the web service returns, or that I
won't be able to maintain a handle on it when I want to kill the
thread later.

I don't think it will just get killed, but the real danger is that
requests might spawn too many threads, and cause a loss of service.

2) Use the Axis2 framework to develop an asynchronous service, as
described here http://www.ibm.com/developerworks/webservices/library/ws-axis2/

Don't have much knowledge about this. sorry...

Would these methods work? Which would you recommend?

In either method, what's the best way to exchange data between this
background process and any future web service calls?

It might actually be better to consider a Producer/Consumer pattern. The
service request produces a Task to be done in the background, and puts
it into a queue. The Consumer is pool of threads that will read from
this task.

As for keeping track of Tasks, you can put them into some shared
data-structure that maps from some ID to the actual Task.

Also, look at the Java Concurrency:
<http://java.sun.com/javase/6/docs/api/java/util/concurrent/package-summary.html>

I also suggest reading Java Concurrency in Practice:
<http://virtualinfinity.net/wordpress/technical-book-recommendations/java-concurrency-in-practice/>

 

[ShaneLM]

I don't think it will just get killed, but the real danger is that
requests might spawn too many threads, and cause a loss of service.


Don't have much knowledge about this. sorry...





It might actually be better to consider a Producer/Consumer pattern. The
service request produces a Task to be done in the background, and puts
it into a queue.  The Consumer is pool of threads that will read from
this task.

As for keeping track of Tasks, you can put them into some shared
data-structure that maps from some ID to the actual Task.

Also, look at the Java Concurrency:
<http://java.sun.com/javase/6/docs/api/java/util/concurrent/package-su...>

I also suggest reading Java Concurrency in Practice:
<http://virtualinfinity.net/wordpress/technical-book-recommendations/j...>

Thanks Arne and Daniel -

It's good to know that the thread won't exit as soon as the web
service call returns. I took a look at your suggestions and don't
think they fit my problem, so we're probably going to go with the
thread approach.

Arne - you suggested using a singleton to share data between the
thread and future web service calls. Sounds great, but i'm curious how
this works. Aren't web service calls supposed to be stateless? And if
so, then wouldn't the singleton be recreated each time the call is
made? Or is there a way to persist the singleton between calls?

Thanks!
Shane

 

[Peter D.]

Thanks Arne and Daniel -

It's good to know that the thread won't exit as soon as the web
service call returns. I took a look at your suggestions and don't
think they fit my problem, so we're probably going to go with the
thread approach.

Arne - you suggested using a singleton to share data between the
thread and future web service calls. Sounds great, but i'm curious how
this works. Aren't web service calls supposed to be stateless? And if
so, then wouldn't the singleton be recreated each time the call is
made? Or is there a way to persist the singleton between calls?

Thanks!
Shane

Check out Executors

http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Executor.html

 

[Arne Vajhøj]

It's good to know that the thread won't exit as soon as the web
service call returns. I took a look at your suggestions and don't
think they fit my problem, so we're probably going to go with the
thread approach.

If you have a full Java EE app server you can use the message queue
and MDB no matter what the task is.

Arne - you suggested using a singleton to share data between the
thread and future web service calls. Sounds great, but i'm curious how
this works. Aren't web service calls supposed to be stateless? And if
so, then wouldn't the singleton be recreated each time the call is
made? Or is there a way to persist the singleton between calls?

Singleton will automatically be preserved between calls. Singletons
are controlled by the JVM and classloader not by the web service
as such.

Yes - usually web services should ideally be stateless. But when
choosing between extremely long response times and state, then
state is better.

Arne

 

[Arne Vajhøj]

Check out Executors

http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Executor.html

Executors is a nice way of having something done in a thread, but is
still starting a thread by app code and not container code, and it still
needs somewhere to store the ref between requests.

Arne

 

[jrobinss]

Hi, caution maybe stupid solution ahead...

Hi, I'm new to java web services and am trying to understand the
context in which they are run. Any pointers to the web service
lifecycle (specifically through Axis2) would be awesome.

I've worked with web services, first using axis1 then JAX-WS. My
conclusion about the technology is that it works, but it's full of
surprises and pitfalls. And threading, complex in plain Java, seemed
even more touchy in web services.

So when I needed some kind of thread independence, for example a
command-line tool for executing web services or a GUI linked to a web
service, I used a workaround: I defined an RMI service. That way I
guaranteed independence of thread between my utility or GUI and my web
services.
Web service <-> RMI <-> anything running, GUI, CLI,...

What thinketh thou all of this?

 

[Lew]

Hi, caution maybe stupid solution ahead...



I've worked with web services, first using axis1 then JAX-WS. My
conclusion about the technology is that it works, but it's full of
surprises and pitfalls. And threading, complex in plain Java, seemed
even more touchy in web services.

So when I needed some kind of thread independence, for example a
command-line tool for executing web services or a GUI linked to a web
service, I used a workaround: I defined an RMI service. That way I
guaranteed independence of thread between my utility or GUI and my web
services.
Web service <-> RMI <-> anything running, GUI, CLI,...

You really hate your operations personnel, don't you?

Arne's advice is better. Web services are a replacement for RMI; it's
a lot of fooferol to use them together.

What thinketh thou all of this?

It's, "What thinkest thou ...". Subject and verb have to agree.

I think it's a lot of operations complexity for no real benefit.

 

[Arne Vajhøj]

I've worked with web services, first using axis1 then JAX-WS. My
conclusion about the technology is that it works, but it's full of
surprises and pitfalls. And threading, complex in plain Java, seemed
even more touchy in web services.

Java web services are usually run inside servlet containers.

And servlet containers has proven over a decade that they
do threading very well.

So when I needed some kind of thread independence, for example a
command-line tool for executing web services or a GUI linked to a web
service, I used a workaround: I defined an RMI service. That way I
guaranteed independence of thread between my utility or GUI and my web
services.
Web service <-> RMI <-> anything running, GUI, CLI,...

I can not see any benefits by adding an extra tier.

Arne

 

[ShaneLM]

Java web services are usually run inside servlet containers.

And servlet containers has proven over a decade that they
do threading very well.


I can not see any benefits by adding an extra tier.

Arne

Thanks everyone for all your help. That warning about a stupid
solution scared me so I made sure to re-think our alternatives.
Although some things are mandated upon us, such as this being a
service, we did not need to spawn a background thread and are planning
on accomplishing something similar by utilizing a timer and using
recurring timer tasks. The information about singletons is good to
know as well.

I appreciate all the help! Hopefully everyone has the day off and is
enjoying it!

Shane

 

[jrobinss]

Ok, thanks for the answers. I now know for sure that my solution was a
bad one. Live and learn.

Thanks everyone for all your help. That warning about a stupid
solution scared me so I made sure to re-think our alternatives.

Sorry, that was a warning about *my* solution, not yours.

I appreciate all the help! Hopefully everyone has the day off and is
enjoying it!

Indians, British, Australians, etc, you mean? ;-)

So much nitpicking on this NG...