I have a client application which accesses a web service api using apache axis.
My client is a service which calls the web service randomly. So I do not know when exactly the interaction happens.
I want to keep the session active betweeen the web service calls.
I am thinking of having a seperate thread which periodically calls a dummy method so that the session never times out? is this a right idea or does it have any draw backs?
Another way is to relogin when ever a "session timed out" exception is thrown while accessing the webservice. But since many objects can interact with the web service this will create new problems like synchronization to be handled.
Related
I have a service layer which is calling a webservice. The number of requests generated by the service layer could potentially be very large and i want to build in some contingency in case the volume of requests becomes to much for the web service to handle. I know i can add some exception handling which can tell if the request failed or not however i don't want to keep hitting the service if its down or struggling to handle the requests.
How can i tell my service layer to stop making calls when the service is unavailable and then resume once its active again? I know this can be done manually using a file containing a flag which the service would check before making a call to the webservice. This flag could then be updated whenever the server goes dowm, however i would prefer something automatic.
Thanks,
I think it is easily could be done with interceptors. Just make your own interceptor and implement the logic in here.
I'm creating a web application with servlets and I need a thread changing a number constantly and when a client do a request it gets the current number.
I tried creating a class with the main method and from there start the thread, then from the servlet get the instance where the thread is running (can this be possible?), but the application never enters to the main method.
Any suggestions?
Thanks
Servlets run in a web container and the web container's main method is out of your control.
If you want to perform any startup operations, then the servlet framework provides context listeners that can be registered with the framework. These listeners are called when your web application starts.
Alternatively, if you want to perform some operation on each incoming request or outgoing response, then you can use servlet filters
You should have a scheduled task that runs on your webserver, that updates that number. There is no "main" method (as in application entry point) in web applications, since each servlet is an independent entry point.
I have a two restful webservices:
getMarketData
stopMarketData
getMarketData pulls the data from external service. stopMarketData will stop the pulling process of data being fetched from external service.
Now the problem is, when I fire getMarketData it creates a connection with the external service and start fetching the data (its continuous process as it continuously fetches the data until we call stopMarketData).
After that if I make a call to stopMarketData webservice it doesn't stop the fetching data process as the connection is not in the context of getMarketData so how can i persist the connection between getMarketData and stopMarketData calls in restful webservice.
I don't think you're supposed to maintain state in RESTful services. How would you scale this solution out to run on multiple machines or even multiple processes?
If you really do want to do this, you will have to somehow place the connection in a global area (such as in the Application object if you're doing JSP or ASP) that is available from multiple requests. Then, the stopMarketData call could get the connection from that global area and close it. This approach is definitely not very scalable.
Another option would be to use an asynchronous technology like Message Driven EJBs. startMarketData and stopMarketData calls would simply post messages to these EJBs to start and stop, respectively.
Hope this helps.
Nate
I have a JAX-WS web service that has been running in a production environment for about two and a half months now and everything seemed to be running perfectly. However, in the last few days I have noticed that it appears that requests to the web service from different clients are becoming intermingled at random. When this happens one request that is currently being processed gets interrupted somehow by second request and the second request completes processing before the first request and the response for the second request is sent to both the first and second requester. The web service works exactly as it's supposed to 98.5% of the time and the other 1.5% of the time this problem seems to be showing up.
When this occurs there are no errors written to the Tomcal logs. The web service uses log4j and the log file for the web service also will have no exceptions when this occurs.
Thanks in advance for any help that you may be able to provide.
From the description this sounds like a threading issue.
Just like in servlets where the programmer must make sure that the code is thread safe so you must make sure that the code in your web service is thread safe.
Just like in servlets, a single instance of you web service implementation will be used for all (concurrent) requests so you must make sure that your code is thread safe.
Does anyone have any insight into transaction options available over web-service calls?
1.) There are two applications that we have that need transactional communication between them.
2.) App1 calls a web service on app 2 and then makes some changes to its own db. the call on app2 and the changes to it's own db need to be co-ordinated. How can we do this? what are the possible options ?
You make the webservice call and if its successful do change in your own DB. If changing your own DB fails then call the webservice to revert the changes done in earlier call. For this to happen the webservice must provide the revert functionality.
For example, the webservice have createUser function then they should have deleteUser function.
It depends what technology stack you are using. In .Net WCF offers transaction features, otherwise the only thing that you can do is minimize the timespan an error can occur.
In previous applications, I've given the service a token to the web service. When the service returns (sync or async) it returns the token. The token has an embedded timestamp. If the timestamp has expired then the transaction is aborted, if not I assume the web service call was successful.
After successful return of the webservice call, the NEXT method call is to record the transaction within your system. This creates a very small window where the system behind the web service and your system will be out of sync. It also lessens the chance that an unexpected error will occur that will prevent the update/insert on your side.
You could try Atomikos ExtremeTransactions. It includes support for WS/SOAP transactions whose rollback spans multiple sites.
Guy