[JBoss JIRA] Created: (JBAS-8820) serialization of SimpleServerDeploymentActionResult
by Alexey Loubyansky (JIRA)
serialization of SimpleServerDeploymentActionResult
---------------------------------------------------
Key: JBAS-8820
URL: https://issues.jboss.org/browse/JBAS-8820
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 7.0.0.Alpha1
Reporter: Alexey Loubyansky
Assignee: Alexey Loubyansky
Fix For: 7.0.0.Alpha2
org.jboss.as.server.client.api.deployment.SimpleServerDeploymentActionResult is a serializable impl of AbstractServerUpdateActionResult which doesn't impl Serializable. The problem is that when SimpleServerDeploymentActionResult is deserialized none of the private fields of AbstractServerUpdateActionResult is initialized. To fix this, AbstractServerUpdateActionResult should implement Serializable.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] Created: (JBMESSAGING-1838) Improve DataSource retry mechanism
by Yong Hao Gao (JIRA)
Improve DataSource retry mechanism
----------------------------------
Key: JBMESSAGING-1838
URL: https://issues.jboss.org/browse/JBMESSAGING-1838
Project: JBoss Messaging
Issue Type: Feature Request
Components: Messaging Core Persistence
Affects Versions: 1.4.7.GA, 1.4.0.SP3.CP11
Reporter: Yong Hao Gao
Assignee: Yong Hao Gao
Fix For: 1.4.0.SP3.CP12, 1.4.8.GA
Currently JBM will retry max 25 times for a non connection failure. That's not good enough when a DB is disconnected and reconnected after max retry has reached. JBM will be in a 'failure' state and requires a re-start of the node.
If we allow user to configure the retry until the DB connection is back, JBM can work on without restart. We can also enable retry on connection failure too.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] Created: (JBMESSAGING-1822) MessageSucker failures cause the delivery of the failed message to stall
by david.boeren (JIRA)
MessageSucker failures cause the delivery of the failed message to stall
------------------------------------------------------------------------
Key: JBMESSAGING-1822
URL: https://jira.jboss.org/browse/JBMESSAGING-1822
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core
Affects Versions: 1.4.6.GA
Reporter: david.boeren
Fix For: Unscheduled
Attachments: helloworld.zip
The MessageSucker is responsible for migrating messages between different members of a cluster, it is a consumer to the remote queue from which it receives messages destined for the queue on the local cluster member.
The onMessage routine, at its most basic, does the following
- bookkeeping for the incoming message, including expiry
- acknowledge the incoming message
- attempt to deliver to the local queue
When the delivery fails, the result is the *appearance* of lost messages. Those messages which are processed during the failure are not redelivered, but they still exist in the database.
The only way I have found to trigger the redelivery of those messages is to redeploy the queue containing the messages and/or restart that app server. Obviously neither approach is acceptable.
In order to trigger the error I created a SOA cluster which *only* shared the JMS database, and no other. I modified the helloworld quickstart to display a counter of messages consumed, clustered the *esb* queue, and then used byteman to trigger the faults.
The byteman rule is as follows, the quickstart will be attached.
RULE throw every fifth send
INTERFACE ProducerDelegate
METHOD send
AT ENTRY
IF callerEquals("MessageSucker.onMessage", true) && (incrementCounter("throwException") % 5 == 0)
DO THROW new IllegalStateException("Deliberate exception")
ENDRULE
This results in an exception being thrown for every fifth message. Once the delivery has quiesced, examine the JBM_MSG and JBM_MSG_REF tables to see the messages which have not been delivered.
The clusters are ports-default and ports-01, the client seeds the gateway by sending 300 messages to the default.
Adding up the counter from each server *plus* the message count from JBM_MSG results in 300 (or multiples thereof for more executions).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months