[JBoss JIRA] Created: (JBESB-1909) JmsConnectionPool overflows sometimes with JBossMQ
by Pavel Kadlec (JIRA)
JmsConnectionPool overflows sometimes with JBossMQ
--------------------------------------------------
Key: JBESB-1909
URL: https://jira.jboss.org/jira/browse/JBESB-1909
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Rosetta
Affects Versions: 4.3
Environment: JBossAS-4.2.2.GA with JBossMQ
Reporter: Pavel Kadlec
The core reason is that JBossMQ's XAConnectionFactory.createSession always creates XASession (is always transacted and with SESSION_TRANSACTED acknowledgement mode), but JBossMessaging's XAConnectionFactory.createSession creates non-xa Session (transacted or non-transacted and with customized acknowledgement mode). The JmsConnectionPool is intended to be used with JBossMessaging behaviour only.
The overflow occurs when caller thread associated with *NO* transaction sends esb message (by jms courier) using *XAConnectionFactory* to the esb service.
In this case the connection pool uses XAConnectionFactory.createSession for creating the session. The pool has hashmaps which key is acknowledgement mode. JBossMQ's XAConnectionFactory.createSession always creates Session with SESSION_TRANSACTED acknowledgement mode. But the pool registers the session under customized acknowledgement mode into the maps (eg. AUTO_ACKNOWLEDGE). When session clean is called, the JmsConnectionPool tries to remove the session from the pool, but uses Session.getAcknowledgement to find out what type of session it is. This returns SESSION_TRANSACTED mode, but session was registered under eg. AUTO_ACKNOWLEDGE mode. The pool is not cleaned up correctly and overflows.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 9 months
[JBoss JIRA] Created: (JBESB-2097) ServiceInvoker Exception details
by Burr Sutter (JIRA)
ServiceInvoker Exception details
--------------------------------
Key: JBESB-2097
URL: https://jira.jboss.org/jira/browse/JBESB-2097
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Rosetta
Affects Versions: 4.4
Reporter: Burr Sutter
Current the ServiceInvoker.deliverSync() method might throw the following exceptions:
MessageDeliverException
RegistryException
FaultMessageException
requestMessage = MessageFactory.getInstance().getMessage();
requestMessage.getProperties().setProperty(Environment.EXCEPTION_ON_DELIVERY_FAILURE,"true");
ServiceInvoker invoker = new ServiceInvoker("MyCategory", "Service99");
replyMessage = invoker.deliverSync(requestMessage,2000);
A service name which does not exist results in a MessageDeliverException, with the following information exposed via a
System.err.println(mde);
11:25:16,179 ERROR [STDERR] org.jboss.soa.esb.listeners.message.MessageDeliverEx
ception: Failed to deliver message [header: [ ]] to Service [MyCategory:Servic
e99]. Check for errors.
It would have made more sense for it to be a RegistryException and the actual message doesn't indicate that there is a lookup problem.
Futhermore, a timeout results in the following MessageDeliverException:
11:45:06,278 ERROR [STDERR] org.jboss.soa.esb.listeners.message.MessageDeliverEx
ception: Failed to deliver message [header: [ To: InVMEpr [ PortReference < <wsa
:Address invm://52455354456173794553425365727669636531/false?false#10000/>, <wsa
:ReferenceProperties jbossesb:passByValue : false/>, <wsa:ReferenceProperties jb
ossesb:type : urn:jboss/esb/epr/type/invm/> > ] ReplyTo: InVMEpr [ PortReference
< <wsa:Address invm://thread-559/>, <wsa:ReferenceProperties jbossesb:passByVal
ue : false/>, <wsa:ReferenceProperties jbossesb:type : urn:jboss/esb/epr/type/in
vm/> > ] ]] to Service [MyCategory:Service1]. Told not to retry.
No indication that the problem is timeout and the "Told not to retry" is a bit terse.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 10 months
[JBoss JIRA] Created: (JBESB-2328) JBossWS getPort not thread safe
by Kevin Conner (JIRA)
JBossWS getPort not thread safe
-------------------------------
Key: JBESB-2328
URL: https://jira.jboss.org/jira/browse/JBESB-2328
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web Services
Affects Versions: 4.4
Reporter: Kevin Conner
Assignee: Kevin Conner
Fix For: 4.4 CP2, 4.5
This has been seen on the SOA 4.3 GA release when concurrent access are being made to getPort.
Caused by: java.util.ConcurrentModificationException
at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:449)
at java.util.AbstractList$Itr.next(AbstractList.java:420)
at org.jboss.ws.metadata.umdm.EndpointMetaData.eagerInitializeOperations(EndpointMetaData.java:538)
at org.jboss.ws.metadata.umdm.EndpointMetaData.initializeInternal(EndpointMetaData.java:525)
at org.jboss.ws.metadata.umdm.EndpointMetaData.eagerInitialize(EndpointMetaData.java:513)
at org.jboss.ws.metadata.builder.jaxws.JAXWSClientMetaDataBuilder.rebuildEndpointMetaData(JAXWSClientMetaDataBuilder.java:308)
at org.jboss.ws.core.jaxws.spi.ServiceDelegateImpl.getPortInternal(ServiceDelegateImpl.java:262)
at org.jboss.ws.core.jaxws.spi.ServiceDelegateImpl.getPort(ServiceDelegateImpl.java:193)
at javax.xml.ws.Service.getPort(Service.java:116)
I reproduced this by updating the Wise-core.jar and jbossesb-soap.jar to the ESB 4.4CP2 versions and modified the webservice_consumer_wise quickstart to send 20 concurrent messages.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 10 months