Bad practice to wait for service to return?

Question

I'm calling a Spring web service which takes approx 5 seconds to return a response. The webservice call takes place within the Tomcat container prior to being deployed to websphere. I've been told by another developer that the call to this service should be handled in a separate java thread as its "bad practice to have the JVM stuck on one line of code for too long" in this case its stuck on the line of code which calls the web service. I disagree and think that if the web service takes 5 or 10 seconds to complete then that's fine, the response will be received and code execution will continue as normal. Am I right ?

Answer 1

I'd make two points:

1. If the subsequent computation depends on the result of that web service, then you don't have a choice anyway and spawning a new thread is just a waste of resources;

2. if this call is fully independent, then there may be a good reason to offload it to a separate thread. Even if five seconds is not much on its own, this may not be (now or in the future of your codebase) the only point where the system pointlessly waits for independent tasks to complete. It is a generally good practice to let independent tasks run independently.

However, if your call is happening within an application deployed into the Tomcat container (this detail is not fully clear from your question), then it is generally a bad practice for a web application to spawn its own child threads. The tasks should be submitted to a container-provided executor service, if there is one.

Answer 2

Synchronous calling webservices is bad idea, it may be work on integration or testing environment but the response will be exponentiate increasing with load on system. You should look at some kind of asynchronous communication.

On ours project we used to a lot of sync communication, all was rewritten to async.