Thanks Alessio Soldano.
If I may follow it up with another question, is there any way that we can cache the WSDL, since each invocation of getPort (...) (via the JAX-WS JBossWS-Native) involves a full parse of the WSDL ? Whats happening in this case is : Many invocations of the client WebService. As it involves invoking another WebService, each of the getPort(...) calls resulted in :
- connecting to the target WSDL location: This can be verified as the WSDL parsing fails when the target host is down. What I mean is, there is no need to connect to the target host and then download the WSDL, if we know that its not gonna change. When I say "WSDL parsing fails", I mean that there are no WSDL parsing statements in the DEBUG log and Exception is thrown before such parsing happens.
- full parse of WSDL: I find the full WSDL printed in the DEBUG log. Probably this is followed by a conversion of XML to Java artefacts, but this is unnecessary time taking operation (in my view) since the target WSDL is the same anyway.
Additionally, I find many open file descriptors accessing the WSDL in the server/<configuration>/data/wsdl/TargetWS/TargetWS001.wsdl (i.e., the WSDL created when I deploy the TargetWS. Though this seems contradictory to the point 1 listed above).
Message was edited by: Rohit Macherla