Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Server Time-out  RSS feed

 
Carlos Calvo Garcia-Cuerva
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Our java ws is the entrance of our processing app. We have to response in 30 seconds, yes or yes, and we want to detect our timeout and this way we can respond to the client correctly with this problem.

I don't know if we can use timers, or something similar. Maybe create a new thread for each request with his timeout definition.

What do you recommend me?

Thanks
 
Ivan Krizsan
Ranch Hand
Posts: 2198
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi!
You do not say a lot about how requests are forwarded from the web service to the processing application, so I can only speculate.
I am assuming that requests to the processing application are processed independent of the thread in the web service which processes the request to the web service - that is, the thread in the web service is able to send a request to the processing application and then continue to do something else while awaiting a reply from the processing application.
If this is the case, then there is no need to create more threads. The web service simply forwards the request to the processing application and then sleeps for 30 seconds. After having slept, the thread in the web service examines whether a response has been produced by the processing application or not and creates an appropriate response accordingly.

If your processing application is not constructed to receive asynchronous requests, as described above, then there are various mechanisms you can use to make it behave in such a way; for instance a queue, a combination of a thread pool and tasks etc.

Finally, if you ask questions here, it does help to outline the problem in greater detail, since this will increase the chance of receiving a useful answer.
Best wishes!
 
Carlos Calvo Garcia-Cuerva
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Ivan, you're right, I didn't explain the problem correctly.

I'll try to explain it better.

We have a java payments gateway what we want to deploy in a app server, in addition we have a ws to accept operations from another systems. Both of them are in the same war.

First I was thinking in a stand alone app, then the app could receive operations listening a socket. This way in the ws we can managing the time-out easily. But... I'd prefer deploying everything in the same war in a app server although the problem is how to resolve the server time-out, because the ws and the app share the same thread.

What do you think about? It's possible to deploy ws+app in the same war? What is the best solution?

Thanks
 
Ivan Krizsan
Ranch Hand
Posts: 2198
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi!
Since you want to run these things in an application server, I would be less inclined to use the solution which involves creating threads and a thread pool.
I would want to invoke the payment gateway asynchronously, as outlined in my previous posting.
There are a few ways that you can do that:
1. EJB 3.1 supports asynchronous calls.
When an asynchronous method is invoked on an EJB, the caller receives a Future object. This object can be polled for a result and, if 30 seconds have passed with no result having arrived, the web service operation "times out".
Reference: http://java.sun.com/developer/technicalArticles/JavaEE/JavaEE6Overview_Part3.html
2. Messaging
More involved than the above alternative, but also more independent of the application server in which the application is to be deployed.
The web service sends (asynchronous) messages to a queue. These messages are received and processed by the payments gateway. Message correlation is used and the payments gateway sends responses to a response queue.
Reference: Java Message Service 2nd Edition, chapter 4.

There are surely other alternatives, but these are the simpler ones that I can think of.
Best wishes!
 
Carlos Calvo Garcia-Cuerva
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you
Your response it's very interesting and it resolve our problem

I think we choose the ejbs solution, because we won't change the app server and we have better knowledge about ejb than messaging

Thank you
 
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!