Re: WS-Addressing OutOfMemoryErrors under load
Am Freitag, den 04.01.2008, 18:19 -0800 schrieb Kyle Sampson:
I'm currently using CXF 2.0.3. While playing around with WS-Addressing, I've
noticed a number of errors that occur when sending lots of messages.
Here, lots of messages = messages being sent in a while(true) loop
I've
been able to reproduce them by making minor changes to the ws_addressing
sample provided with CXF.
During these tests, I turned off logging for anything less than WARNING. In
Client.java, I changed the following lines:
implicitPropagation(port);
explicitPropagation(port);
implicitPropagation(port);
to the following:
int i = 0;
while(true) {
port.greetMeOneWay(Kyle);
i++;
if(i % 10 == 0) {
System.out.println(Sent + i + messages.);
}
}
Is there a SOAP client from any web service stack (Metro? Axis?
Spring-WS?) that *could* support nonstop web service calls at the rate
of a while(true) loop? Had CXF failed on your hardware at 7600 or
76,000 attempts instead of just 760, would you also be sending this
email noting a problem, or would that have been within acceptable bounds
of failure?
I'm not sure the problem you're reporting is:
1.) Given our hardware, and CXF's architecture, CXF failed far too soon
within a while(true) loop; i.e., tests with Axis or Metro gave a far
greater number of calls before failing. That would be a legitimate
concern for us to look into.
or
2.) CXF's client and server failed at *anytime* during a while(true)
loop of web service calls--i.e., you'd be sending this email if CXF
clients had failed at iteration 760,000. In this case, before I can be
convinced this is an error, I would first need to see Axis or Metro
clients be able to handle such while(true) rate calls indefinitely.
After calling greetMeOneWay() around 760 times in this way, I get an
OutOfMemoryError. I profiled the client and server using YourKit, and both
the client and server seem to have a memory leak -- the client runs out of
memory first. The problem seems to be MAPCodec.uncorrelatedExchanges map --
it's using nearly all the heap memory available.
Is that necessarily *leaking*, or just the saving of state for each of
the hundreds of requests waiting for a response?
Regards,
Glen
Location of JAX-WS Handler configuration file
Hello, The handlerChain annotation[1] on an SEI implementation class has a file member-value that indicates the location of the JAX-WS handler configuration file (here[2] for example) relative to the SEI implementation containing this annotation. I'm not certain if this relative location refers to the config file's location at *compile* time with respect to the Java source file, or the config file's location at *run-time* (after the source file is compiled into bytecode). If at compile time, a file='handler.xml' value for the HandlerChain annotation would indicate that the file needs to be in the same directory as the java source file. If at run time, a file=handler.xml value would indicate that the file needs to be at the root of the classpath (for a deployed webapp containing the service, at the root of the WEB-INF/classes directory.) Which is it? The heart of this question is when the config file gets read--at compilation time or at run time. Thanks, Glen [1] https://jax-ws.dev.java.net/nonav/2.1.3/docs/annotations.html#2.6% 20javax.jws.HandlerChain%7Coutline [2] http://svn.apache.org/viewvc/incubator/cxf/trunk/distribution/src/main/release/samples/jaxws_handlers/src/demo/handlers/common/demo_handlers.xml?revision=566980view=markup
Re: Location of JAX-WS Handler configuration file
OK, through trial and error I was able to answer my own question. GlassFish Metro: The JAX-WS handler chain configuration file can either be placed in the same folder as the bytecode of the SEI implementation that references it, or as a regular resource file in the classpath (i.e., for a web app, WEB-INF/classes/handlers.xml.) I suspect the latter is preferable, as a Mavenized webapp allows you to place such resource files within the src/main/resources directory, for Maven to subsequently place in the classpath for you when you run mvn war:war. CXF: Unfortunately, the config file can only be placed within the same directory as the bytecode for the SEI implementation class. It cannot read the file as a normal resource in WEB-INF/classes. I think this is a bug--I'll submit a JIRA for it. Thanks, Glen Am Samstag, den 05.01.2008, 09:33 -0500 schrieb Glen Mazza: Hello, The handlerChain annotation[1] on an SEI implementation class has a file member-value that indicates the location of the JAX-WS handler configuration file (here[2] for example) relative to the SEI implementation containing this annotation. I'm not certain if this relative location refers to the config file's location at *compile* time with respect to the Java source file, or the config file's location at *run-time* (after the source file is compiled into bytecode). If at compile time, a file='handler.xml' value for the HandlerChain annotation would indicate that the file needs to be in the same directory as the java source file. If at run time, a file=handler.xml value would indicate that the file needs to be at the root of the classpath (for a deployed webapp containing the service, at the root of the WEB-INF/classes directory.) Which is it? The heart of this question is when the config file gets read--at compilation time or at run time. Thanks, Glen [1] https://jax-ws.dev.java.net/nonav/2.1.3/docs/annotations.html#2.6% 20javax.jws.HandlerChain%7Coutline [2] http://svn.apache.org/viewvc/incubator/cxf/trunk/distribution/src/main/release/samples/jaxws_handlers/src/demo/handlers/common/demo_handlers.xml?revision=566980view=markup
Re: Location of JAX-WS Handler configuration file
This may actually not be a CXF bug after all. JSR-181, Version 2.0, Section 4.6.1 appears to indicate that the configuration file is referenced with respect to the source or compiled class file, not the classpath in general. I don't like this rule but that's the rule. Metro will try to resolve with respect to either the compiled SEI or the classpath[3], but that can be considered riskier/less robust, because if the config file is accidentally placed in both locations but updated only in one, Metro could still be following the older Handler chain rules of the other file. I guess I'm neutral on CXF adopting Metro's philosophy here. I can see either way. Glen [3] https://jax-ws.dev.java.net/nonav/2.1.3/docs/handlers.html, quote: When packaging the service, the handlers.xml file must be in the classpath within the WAR file, either directly under WEB-INF/classes or further down in the same package as the service class file. Am Samstag, den 05.01.2008, 12:24 -0500 schrieb Glen Mazza: OK, through trial and error I was able to answer my own question. GlassFish Metro: The JAX-WS handler chain configuration file can either be placed in the same folder as the bytecode of the SEI implementation that references it, or as a regular resource file in the classpath (i.e., for a web app, WEB-INF/classes/handlers.xml.) I suspect the latter is preferable, as a Mavenized webapp allows you to place such resource files within the src/main/resources directory, for Maven to subsequently place in the classpath for you when you run mvn war:war. CXF: Unfortunately, the config file can only be placed within the same directory as the bytecode for the SEI implementation class. It cannot read the file as a normal resource in WEB-INF/classes. I think this is a bug--I'll submit a JIRA for it. Thanks, Glen Am Samstag, den 05.01.2008, 09:33 -0500 schrieb Glen Mazza: Hello, The handlerChain annotation[1] on an SEI implementation class has a file member-value that indicates the location of the JAX-WS handler configuration file (here[2] for example) relative to the SEI implementation containing this annotation. I'm not certain if this relative location refers to the config file's location at *compile* time with respect to the Java source file, or the config file's location at *run-time* (after the source file is compiled into bytecode). If at compile time, a file='handler.xml' value for the HandlerChain annotation would indicate that the file needs to be in the same directory as the java source file. If at run time, a file=handler.xml value would indicate that the file needs to be at the root of the classpath (for a deployed webapp containing the service, at the root of the WEB-INF/classes directory.) Which is it? The heart of this question is when the config file gets read--at compilation time or at run time. Thanks, Glen [1] https://jax-ws.dev.java.net/nonav/2.1.3/docs/annotations.html#2.6% 20javax.jws.HandlerChain%7Coutline [2] http://svn.apache.org/viewvc/incubator/cxf/trunk/distribution/src/main/release/samples/jaxws_handlers/src/demo/handlers/common/demo_handlers.xml?revision=566980view=markup
