[jbossws-issues] [JBoss JIRA] Created: (JBWS-1878) ConcurrentModificationException in JAXWS Handler when requests hit JBoss during application deployment
ConcurrentModificationException in JAXWS Handler when requests hit JBoss during
application deployment
------------------------------------------------------------------------------------------------------
Key: JBWS-1878
URL: http://jira.jboss.com/jira/browse/JBWS-1878
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-jaxws
Affects Versions: jbossws-2.0.1
Environment: AIX 5.3 ppc64, IBM JVM 9 (1.5.0), JBoss 4.2.1.GA with JBossWS
2.0.1.GA
Reporter: Wojciech Kudla
Priority: Critical
When SOAP requests hit JBoss during application deployment they are somewhat queued and
get processed just after the application starts. Everything works fine if the are only
several requests. If there are more (like 30 or above) before the application starts,
HandlerResolverImpl causes ConcurrentModificationException at line 22
(getHandlerChain()).
This exception does not cause the application to stop working, but results in a very
strange behaviour, namely: every request goes only through JAXWS Handler twice (on inbound
and outbound traffic) but does not hit service implementation (in my case - EJB3 SLSB).
The only clue for me to resolve this problem was to stick to the
ConcurrentModificationException and its stacktrace. Going down this path I decided to
modify some code in class org.jboss.ws.core.jaxws.handler.HandlerDelegateJAXWS. I
synchronized a block of code responsible for initiating handler chains, so the modified
method looks like this:
public boolean callRequestHandlerChain(ServerEndpointMetaData sepMetaData, HandlerType
type)
{
log.debug("callRequestHandlerChain: " + type);
// Initialize the handler chain
if (isInitialized() == false)
{
synchronized(resolver) {
resolver.initHandlerChain(sepMetaData, HandlerType.PRE, true);
resolver.initHandlerChain(sepMetaData, HandlerType.ENDPOINT, true);
resolver.initHandlerChain(sepMetaData, HandlerType.POST, true);
setInitialized(true);
}
}
HandlerChainExecutor executor = createExecutor(sepMetaData, type);
MessageContext msgContext =
(MessageContext)MessageContextAssociation.peekMessageContext();
return executor.handleMessage(msgContext);
}
I tried to do synchronized(this) at the beginning but it very quickly resulted in unstable
AS behaviour and stopping JVM with a core dump in the end (SIC!).
Since we are talking about serious production deployment in 5 days (servicing ca. 5000
SOAP requests per hour) , I decided to incorporate my fix into the environment, but I am
not completely sure wheter my fix imposes any performance pitfalls.
If you find a better idea to solve this problem, please be quick to publish a solution :)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira