February 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCLUSTER-284) Deprecate use of term "partition" (HAPartition, ClusterPartition, etc)

by Paul Ferraro (JIRA)

Deprecate use of term "partition" (HAPartition, ClusterPartition, etc) ---------------------------------------------------------------------- Key: JBCLUSTER-284 URL: https://jira.jboss.org/browse/JBCLUSTER-284 Project: JBoss Clustering Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: HA-Server-API 1.2.0.Final , HA-Server-Cache-JBC 2.3.0.Final, HA-Server-API 1.1.1GA, HA-Client 1.1.1.GA Reporter: Paul Ferraro Assignee: Paul Ferraro Priority: Minor Fix For: HA-Server-Cache-JBC 2.4.0.Final , HA-Server-API 2.0.0.Beta1, HA-Server-Core 1.0.0.Beta1, HA-Server-API 2.0.0.Final, HA-Client 2.0.0.BETA1 The term "partition" should be globally replaced by the term "cluster". This affects public interfaces (the deprecation of which need to be fully backwards compatible), public implementation classes, member variables, system properties, Javadocs, and clustering documentation. -- 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

14 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-7941) ClusterPartition should not send service name twice per message

by Brian Stansberry (JIRA)

ClusterPartition should not send service name twice per message --------------------------------------------------------------- Key: JBAS-7941 URL: https://jira.jboss.org/jira/browse/JBAS-7941 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-6.0.0.M4 ClusterPartition uses a custom RpcDispatcher.Marshaller that encodes the serviceName of the target service in the first element of an Object[]. The service name is also encoded in the "name" property of the MethodCall that forms the second element of the Object[]. This is inefficient: 1) It increases the size of the over-the-wire message. 2) It forces each recipient to remove the serviceName from the MethodCall.name to figure out the actual method name. Change this so the sender's RpcDispatcher.Marshaller removes the serviceName from MethodCall.name before marshalling it. -- 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

14 years, 10 months

2
4
0 / 0

[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

14 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2236) Singleton bean fails to call @PreDestroy method

by Vidas . (JIRA)

Singleton bean fails to call @PreDestroy method ----------------------------------------------- Key: EJBTHREE-2236 URL: https://issues.jboss.org/browse/EJBTHREE-2236 Project: EJB 3.0 Issue Type: Bug Components: ejb3 Environment: Apple Mac OS X, JBossAS 6.0.0.Final Reporter: Vidas . JBoss fails to call @PreDestroy lifecycle method, annotated with transaction attribute REQUIRES_NEW, while @Singleton bean is annotated with transaction attribute MANDATORY. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

3
10
0 / 0

[JBoss JIRA] Created: (JGRP-1050) Fix JGroups pom file and make JGroups OSGi compliant

by Bulat Nigmatullin (JIRA)

Fix JGroups pom file and make JGroups OSGi compliant ---------------------------------------------------- Key: JGRP-1050 URL: https://jira.jboss.org/jira/browse/JGRP-1050 Project: JGroups Issue Type: Patch Reporter: Bulat Nigmatullin Assignee: Bela Ban Priority: Optional 1. Fix Maven build script, so it will produce the same result as ant build script. 2. Make Maven produced jar's to contain MANIFEST.MF with OSGi info. -- 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

14 years, 10 months

6
17
0 / 0

[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

14 years, 10 months

1
6
0 / 0

[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

14 years, 10 months

5
35
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2011