[JBoss JIRA] Created: (JBESB-866) jUDDI retains invalid EPRs
by Jiri Pechanec (JIRA)
jUDDI retains invalid EPRs
--------------------------
Key: JBESB-866
URL: http://jira.jboss.com/jira/browse/JBESB-866
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Registry and Repository
Affects Versions: 4.2 Milestone Release 3
Reporter: Jiri Pechanec
Assigned To: Mark Little
If the ESB is terminated (crashes) it will retain EPRs in the database. Unfortunately when the EPR is changed e.g. by renaming of underlaying queue, both old and new EPRs are stored in jUDDI registry on the next start. Then under heavier load both EPRs are selected with the result of lot error messages related to unavailable EPR.
--
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, 2 months
[JBoss JIRA] Created: (JBESB-1457) Store original replyTo when invoking jBPM process
by Jiri Pechanec (JIRA)
Store original replyTo when invoking jBPM process
-------------------------------------------------
Key: JBESB-1457
URL: http://jira.jboss.com/jira/browse/JBESB-1457
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Process flow
Affects Versions: 4.2.1 CP1
Reporter: Jiri Pechanec
Assigned To: Kurt Stam
Priority: Critical
Fix For: 4.2.1 CP1
The jBPM process use now be default requires to use async processing. The problem is that there is now no way for the caller how to specify reply address. The replyTo/faultTo headers are used for internal jBPM message sending.
I think that there should exist standard mechanism that will store original replayTo/faultTo values and allow to route them final response.
This is so common and basic functionality that customer should not be required to invent and implement its own mechanism.
--
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, 3 months
[JBoss JIRA] Created: (JBESB-1901) Stateful rule service cannot be used in cluster and does not persist its state
by Jiri Pechanec (JIRA)
Stateful rule service cannot be used in cluster and does not persist its state
------------------------------------------------------------------------------
Key: JBESB-1901
URL: https://jira.jboss.org/jira/browse/JBESB-1901
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Content Based Routing, Documentation
Affects Versions: 4.4
Reporter: Jiri Pechanec
Fix For: 4.4 CP1
If the rule service is stateful and used in cluster it does not guarantee that all messages are processed by the same service instance . As the state is not replicated over the service instances it can break the business logic. This limitation has to be either documented or fixed.
Moreover the state of working memory is not persisted in between invocations and thus can be lost in case of crash - which can affect business logic - this limitation must be documented.
--
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, 3 months