Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

JAX-WS client within JAX-RS (Jersey) WS freezes GF2 app server

 
R van Vliet
Ranch Hand
Posts: 144
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi guys,

I have an odd problem. I want to access a JAX-WS webservice deployed on a GF2 app server from a JAX-RS based webservice running on Jersey within GF2. Now, the second the JAX-RS service is accessed concurrently (so, more than a few requests come in at roughly the same time) the SOAP web service client freezes on this part of the code :


Naming changed but assume namespace and such are correct. Now if I do this in a seperate java app I can do this all day long with as many threads as I'd like. If I load test the JAX-RS call without this bit of code it always works just fine. However this bit of code inside a JAX-RS method hangs the server. It looks like the HTTP listener no longer responds.

Anyone any ideas?


 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13071
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My first question when I see the words "hang the server" is - do you mean the server CPU is maxed out -or- the server no longer answers -or- what.

The title says freezes the server, the content says client freezes - which is it?

Bill
 
R van Vliet
Ranch Hand
Posts: 144
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Perfectly valid question, it was causing the http-worker threads of GF to block. I've now figured out why. We were running both web services (so, the SOAP and the RESTful one) on the same virtual server/http listener within GF. Since the JAX-RS one was requesting the WSDL of the SOAP one on a per request basis it was a matter of time before it grinded to a halt.

To simplify the explanation, assume GF reserves a single http worker thread for port 8080 where both of these are running. It will grab that worker thread for my JAX-RS request, which in turn wants to request a WSDL. Since the only worker thread is then blocked it cannot return the WSDL.

In hindsight a perfectly obvious problem ;)
 
Ivan Krizsan
Ranch Hand
Posts: 2198
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi!
I recall having seen some setting in GlassFish that allowed me to configure the size of a threadpool from which threads serving requests are taken.
See this article: http://blogs.sun.com/binublog/entry/monitoring_in_glassfish
Thus I feel that increasing the size of this threadpool may solve your problem.
With reservation for having misunderstood the question...
Best wishes!
 
R van Vliet
Ranch Hand
Posts: 144
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ivan Krizsan wrote:Hi!
I recall having seen some setting in GlassFish that allowed me to configure the size of a threadpool from which threads serving requests are taken.
See this article: http://blogs.sun.com/binublog/entry/monitoring_in_glassfish
Thus I feel that increasing the size of this threadpool may solve your problem.
With reservation for having misunderstood the question...
Best wishes!


Hi Ivan,

Although this would reduce the problem since it's less likely that all threads are waiting for a nested request to finish the problem will still occur during heavy loads. Basically we should either do the nested (or sub) request asynchronously or to a different http-listener. We were able to reproduce the issue with 40 threads in the pool so it's not a fix.
 
Ivan Krizsan
Ranch Hand
Posts: 2198
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
R van Vliet wrote:We were able to reproduce the issue with 40 threads in the pool so it's not a fix.

Thanks for sharing that interesting piece of information!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic