[JBoss JIRA] Created: (JBMESSAGING-1774) maxDeliveryAttempts for MessageSucker shouldn't be -1, resulting message loss
by Howard Gao (JIRA)
maxDeliveryAttempts for MessageSucker shouldn't be -1, resulting message loss
-----------------------------------------------------------------------------
Key: JBMESSAGING-1774
URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1774
Project: JBoss Messaging
Issue Type: Bug
Affects Versions: 1.4.6.GA, 1.4.5.GA, 1.4.0.SP3.CP09
Reporter: Howard Gao
Assignee: Howard Gao
Fix For: 1.4.0.SP3.CP10, 1.4.6.GA.SP1, 1.4.7.GA
When a MessageSucker is created, its consumer's maxDeliveryAttempts is set to -1. This will cause possible message loss in the following scenario:
1. in a 2-node cluster, messages are sent to distributed destination on node 1 but are consumed on node 0. Message sucker sucks messages from node 1 and sends to node 0.
2. During the process, node0 shut down normally. Then if there are some prefetched messages still in message sucker, they will be cancelled back to node1.
3. Because the maxDeliveryAttempts is -1, the messages cancelled will be instantly put to DLQ or, if there is no DLQ configured, be discarded.
>From user's perspective, the message shouldn't be discarded this way.
To fix this:
Set the maxDeliveryAttempts to 1.
--
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
15 years, 10 months
[JBoss JIRA] Created: (JBRULES-2361) ServiceManager Mobility, Proxy and Hybrid
by Mark Proctor (JIRA)
ServiceManager Mobility, Proxy and Hybrid
-----------------------------------------
Key: JBRULES-2361
URL: https://jira.jboss.org/jira/browse/JBRULES-2361
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: All
Reporter: Mark Proctor
Assignee: Mauricio Salatino
Machines
A B
C
ServiceManager (sm1) is deployed physically on A. With ksessions k1, k2, k3.
C gets a remote connection to sm1 and starts working on k1.
ServiceManager (sm2) is deployed physically on B.
Seamless movement
k1 is moved physically from sm1 to sm2. C needs to be able to seamlessly keep working k1, unaware of the move.
Seamless proxy
B gets remote connection to k2 on A's SM1. B registers k2 in sm2. If C was to lookup sm2.k2 it would be talking via a proxy, via B to C.
Hybrid
C decides that it needs to move k1 locally for continued work. Currently it only has a remote sm1. k1 should stayed regestered on sm1, but once moved locally to C it would effectively proxy from A to C. If k1 is on C, have we made a "sm1" that is partially natively on A and partially natively on C? This is almost like a clustered sm....
--
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
15 years, 10 months