[JBoss JIRA] Created: (JBESB-1540) WebService invocation is sometimes handled by CoyoteInvoker belonging to undeployed package
by Jiri Pechanec (JIRA)
WebService invocation is sometimes handled by CoyoteInvoker belonging to undeployed package
-------------------------------------------------------------------------------------------
Key: JBESB-1540
URL: http://jira.jboss.com/jira/browse/JBESB-1540
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web Services
Affects Versions: 4.2.1
Reporter: Jiri Pechanec
Assigned To: Kevin Conner
Priority: Minor
Attachments: server.log.gz
There were multiple packages deployed/undeployed in the test. The deployment of Quickstart_webservice_mtom.esb is started on line 413471. This package starts coyote invoker with hashCode 17a4c54 at the line 413681. The undeploymetn of this package starts on line 414408. The CoyoteInvoker with the given hashCode is stopped at line 414457.
The Quickstart_webservice_wsa.esb package deployment starts at line 414599.
The CoyotInvoker with hashCode d93db8 is started at line 414806.
Then the test message is sent via HTTP/SOAP and this request fails on line 515535 because it was served by the CoyoteInvoker with hashCode 17a4c54 so the one that belongs to previously undeployed package.
--
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
16 years, 7 months
[JBoss JIRA] Created: (JBESB-1710) Documentation of Standalone mode in Quickstarts is confusing
by Tom Cunningham (JIRA)
Documentation of Standalone mode in Quickstarts is confusing
------------------------------------------------------------
Key: JBESB-1710
URL: http://jira.jboss.com/jira/browse/JBESB-1710
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Documentation, Examples
Affects Versions: 4.2.1 CP2
Reporter: Tom Cunningham
In the readme.txt of every QuickStart, we document how to run in standalone mode. Do we really want to do this? Standalone mode seems like an edge case that we support, and listing it in every QS readme.txt is confusing to first time users (see forum post reference). Maybe we should have a standalone guide that describes how to run QS's in standalone mode, and focus the QS readmes on the most common method of running the QS's (running in ESB server or JBossAS+ESB).
--
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
16 years, 9 months
[JBoss JIRA] Created: (JBESB-1774) Messages are returned to client from the wrong service
by Mika Leino (JIRA)
Messages are returned to client from the wrong service
------------------------------------------------------
Key: JBESB-1774
URL: http://jira.jboss.com/jira/browse/JBESB-1774
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Process flow
Affects Versions: 4.2.1 CP1
Environment: Windows Server 2003
Reporter: Mika Leino
Attachments: service_A_jboss-esb.xml, service_B_jboss-esb.xml
We have a setup in which a client calls an ESB service (service A) with a webservice interface and this service then calls on another ESB service (service B). Both of the services have their action pipelines set to be "RequestResponse".
For some reason the first attempt to handle the client's message always fails as the message is returned to the client from service B. As the message never returns to service A it assumes an unresponsive EPR and resends the message which on the second attempt returns to service A.
The first attempt looks like this:
client -> service A -> service B -> client
And the second like this:
(client ->) service A -> service B -> service A -> client
Unfortunately the client interpreters the first response as the one it is waiting for and fails as service A has not made the necessary changes to the message. The second attempt produces a valid response but the client is no longer listening for it.
--
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
16 years, 11 months
[JBoss JIRA] Created: (JBESB-1695) jBPM datasource should be XA datasource
by Jiri Pechanec (JIRA)
jBPM datasource should be XA datasource
---------------------------------------
Key: JBESB-1695
URL: http://jira.jboss.com/jira/browse/JBESB-1695
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Process flow, Rosetta
Affects Versions: 4.2.1 CP2
Reporter: Jiri Pechanec
Assigned To: Kevin Conner
Fix For: 4.2.1 CP3
If the SQL listener with transactions is used configured according helloworld_tx_sql and is enhanced with jBPM use - start service, it fails because both datasources are local.
To prevent the issue these steps should be done
1) Change the jBPM DS to be XA datasource - this means that schme toll must be also modified
2) Change QS to use H2 database and XA datasource - it serves users as guidline
3) Switch to h2 database for all datasources
--
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
17 years
[JBoss JIRA] Created: (JBESB-1650) Clean up OracleAQ documentation
by Tom Cunningham (JIRA)
Clean up OracleAQ documentation
-------------------------------
Key: JBESB-1650
URL: http://jira.jboss.com/jira/browse/JBESB-1650
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Message Store
Affects Versions: 4.2.1 CP2
Reporter: Tom Cunningham
Assigned To: Tom Cunningham
Fix For: 4.2.1 CP3
Got some notes from Narayanan Raghavan about his experience with the OracleAQ message provider. They are using it and it is working well but the experience getting it configured could be a little smoother :
- they didn't need ojdbc14.jar (need to double check this)
- they needed the "full version" of cglib.jar (the full version is in the EAP)
- they found the sample jboss-esb.xml confusing - it talks about moving a message from one OracleAQ -> another OracleAQ, and there should be a sample provided of moving a message from OracleAQ - > JBoss Messaging
--
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
17 years