We are getting the following exception in the Production server. There are 2 web services, first webservice internally calls the the second WS.
when we are processing the second webservice response at the first webservice side, we are getting the SAX Exception at the first web service side .
The first webservice has been used in a registration portal and it internally calls the second Webservice . The architecture of the project is as follows
Portal ---> WebService 1 ----> WebService2
The strange thing is, After restarting the server ,
if the portal sends a single request , The webservice1 internally calls WS2 and process the response with out any issue .
if the portal sends bulk request to that Webservice1, then the WS1 internally calls WS2 while processing the response , we are getting this SAXException at the first WS1 side and all the subsequent requests also getting failed while processing the response at the WS1.
we are using Sun application server with axis 1.4.
Have you tried using a packet sniffer, TCP monitor or SOAP proxy to look at the request and response messages between the two web services?
This way, you will be able to tell what is wrong with the message and this will, most likely, give you a clue to where in the code to search for the problem.
Packet sniffer: Wireshark http://www.wireshark.org SOAP proxy/monitor tool Membrane: http://www.membrane-soa.org/soap-monitor/ A TCP monitor can be found in Eclipse and NetBeans IDEs.
We got this issue in the Production .The problem is here, we are able to simulate only in the SVT ( Stress Volume Testing ) Environment not in the development environment.
For the first (single) request its working fine for the bulk request from the portal, its not working . is there any issue with the stub .
we have analyzed the code everything looks ok .
After restarting the server ,if the portal sends bulk request to that Webservice1. The WS1 is not able to process the WS2 response . This is strange .
is there any threading issue ?.
Furthermore, this problem occurs randomly. If I restart the application server, in most cases I won't have the problem anymore.
If you can reproduce the problem, then that is good news, regardless of the environment.
WireShark is not intrusive, meaning that you can record TCP traffic without modifying clients or servers.
Personally, I would not trust code review, but would want to see how the problem manifests itself.
There can be a problem with frameworks etc, so it may not even be your own code.
In a test environment that is not the development environment, you can still do remote debugging or use BTrace to log information about the program under observation.
I dare not say anything about threading issues without having carefully studied the design of the system.