March 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBMESSAGING-1619) add example TCP cluster configuration

by Yong Hao Gao (JIRA)

[ https://issues.jboss.org/browse/JBMESSAGING-1619?page=com.atlassian.jira.... ] Yong Hao Gao updated JBMESSAGING-1619: -------------------------------------- Fix Version/s: 1.4.8.SP11 (was: 1.4.8.SP10) > add example TCP cluster configuration > ------------------------------------- > > Key: JBMESSAGING-1619 > URL: https://issues.jboss.org/browse/JBMESSAGING-1619 > Project: JBoss Messaging > Issue Type: Bug > Components: JMS Clustering > Affects Versions: 1.4.0.SP3.CP07 > Reporter: Dennis Reed > Assignee: Tyronne Wickramarathne > Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11 > > > Add an example TCP cluster configuration (commented out) to all the example *-persistence-service.xml files. > This will make it easier for users who have issues with UDP multicast to configure it to use TCP clustering. > (The same thing is being done to all the EAP configurations that don't already include this). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBMESSAGING-1615) Programmatic way to check the state of a topic

by Yong Hao Gao (JIRA)

[ https://issues.jboss.org/browse/JBMESSAGING-1615?page=com.atlassian.jira.... ] Yong Hao Gao updated JBMESSAGING-1615: -------------------------------------- Fix Version/s: 1.4.8.SP11 (was: 1.4.8.SP10) > Programmatic way to check the state of a topic > ---------------------------------------------- > > Key: JBMESSAGING-1615 > URL: https://issues.jboss.org/browse/JBMESSAGING-1615 > Project: JBoss Messaging > Issue Type: Feature Request > Affects Versions: 1.4.1.GA > Reporter: Colin Mondesir > Assignee: Yong Hao Gao > Priority: Minor > Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11 > > > When the deployTopic(String, String) method is called we have found there is a slight delay before the topic is available to create MessageConsumer. > Is there a programmatic way of checking the state that the topic is in, so that we don't have to wait an arbitrary period of time before creating the Consumer? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBMESSAGING-1610) expose jbossInternalLifecycle method on jms destination mbeans

by Yong Hao Gao (JIRA)

[ https://issues.jboss.org/browse/JBMESSAGING-1610?page=com.atlassian.jira.... ] Yong Hao Gao updated JBMESSAGING-1610: -------------------------------------- Fix Version/s: 1.4.8.SP11 (was: 1.4.8.SP10) > expose jbossInternalLifecycle method on jms destination mbeans > -------------------------------------------------------------- > > Key: JBMESSAGING-1610 > URL: https://issues.jboss.org/browse/JBMESSAGING-1610 > Project: JBoss Messaging > Issue Type: Task > Components: AS Integration > Affects Versions: 1.4.3.GA > Reporter: Emanuel Muckenhuber > Assignee: Yong Hao Gao > Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11 > > > Currently the Queue and Topic xmbean definitions don't expose the jbossInternalLifecycle(String method). This method is needed that the lifecycle and state changes of a mbean are handled by microcontainer (AS5). Otherwise profileservice cannot determine the current state and a stopped jms destination would be still exposed as running to JON/JOPR. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBMESSAGING-1631) Messages are piling up in the queues in clustered environment and not pulled by message sucker

by Yong Hao Gao (JIRA)

[ https://issues.jboss.org/browse/JBMESSAGING-1631?page=com.atlassian.jira.... ] Yong Hao Gao updated JBMESSAGING-1631: -------------------------------------- Fix Version/s: 1.4.8.SP11 (was: 1.4.8.SP10) > Messages are piling up in the queues in clustered environment and not pulled by message sucker > ---------------------------------------------------------------------------------------------- > > Key: JBMESSAGING-1631 > URL: https://issues.jboss.org/browse/JBMESSAGING-1631 > Project: JBoss Messaging > Issue Type: Bug > Components: JMS Clustering > Affects Versions: 1.4.0.SP3.CP08 > Environment: Cluster of a few JBoss 4.2.3 servers with JBM 1.4.2.GA-SP1 or 1.4.0.SP3_CP08 running on x64 windows servers. > JBoss Remoting 2.5.1 or 2.2.3 > Clustered XA connection factory, clustered queues, both server and client (MDBs) are deployed as one application - identical deployment for all servers in a cluster > Reporter: Victor Starenky > Assignee: Yong Hao Gao > Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11 > > Attachments: 1631-test-source.zip, logs-and-config-prod.zip, logs-and-config-test.zip, TestRecommendationSentProcessorMDB.java > > > We have an EJB3 application is running on a cluster of 7 servers. > All servers have the same application farmed across them. > We have a clustered queue and using clustered connection factory. > Originally we ran into the bug JBMESSAGING-1456 and while testing the fix ran into a different problem. After the cluster was running for some time (usually overnight with lots of heavy background processing hapenning at that time) we see messages are "piling up" in some queues on some nodes. > Sympthoms are: > MessageCount is not zero (rather in the order of hundreeds), DeliveringCount is zero. These nodes have ConsumerCount=0 for the queues experiencing the problem. Message sucker is configured as far as I can tell. Looks like the problem might be related to client and/or server failover leaving some nodes without consumers while sucker not doing it's job (if I understand it correctly). > Once we bump the timeout values much higher than they are in the original config files the problem seems to disappear or at least show up much less frequently. Specifically I'm talking about these values: > messaging-service.xml: > <attribute name="FailoverStartTimeout">180000</attribute> > remoting-bisocket-service.xml: > <attribute name="clientLeasePeriod" isParam="true">30000</attribute> > <attribute name="validatorPingPeriod" isParam="true">30000</attribute> > <attribute name="validatorPingTimeout" isParam="true">20000</attribute> > <attribute name="registerCallbackListener">false</attribute> > <attribute name="timeout" isParam="true">240000</attribute> > While this serves as a temporary workaround we don't feel we can rely on JBM in a production clustered environment without having failover working properly. > This is a big showstopper for us at the moment. > Attached are the log files from the prod environment of 7 servers with the config files as well as log files from the test environment with just 2 servers (having same issue) and corresponding configs. The logs were produced by the test version of the messaging code with added logging as per JBMESSAGING-1456. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBMESSAGING-1621) Provide complete message ordering in a clustered environment

by Yong Hao Gao (JIRA)

[ https://issues.jboss.org/browse/JBMESSAGING-1621?page=com.atlassian.jira.... ] Yong Hao Gao updated JBMESSAGING-1621: -------------------------------------- Fix Version/s: 1.4.8.SP11 (was: 1.4.8.SP10) > Provide complete message ordering in a clustered environment > ------------------------------------------------------------ > > Key: JBMESSAGING-1621 > URL: https://issues.jboss.org/browse/JBMESSAGING-1621 > Project: JBoss Messaging > Issue Type: Feature Request > Components: JMS Clustering > Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA > Reporter: Yusuke Yamamoto > Assignee: Yong Hao Gao > Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11 > > > While JBMESSAGING-1416 states message ordering feature in a singleton configuration, customer is also requesting a complete message ordering feature which is applicable in a clustered environment. > Here's the background: > In the case JMS is used, both performance and scalability are priority. > There is a conflict between scalable JMS implementation and complete message ordering feature since order aware messages cannot be processed concurrently. > But order unaware queues should be still processed in parallel for better throughput. > Additionally, there are some cases that no downtime is acceptable. But HA-Singleton requires certain amount of time to fail-over the service to other node. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBMESSAGING-1684) Message remain in the queue and do not get dispatched

by Yong Hao Gao (JIRA)

[ https://issues.jboss.org/browse/JBMESSAGING-1684?page=com.atlassian.jira.... ] Yong Hao Gao updated JBMESSAGING-1684: -------------------------------------- Fix Version/s: 1.4.8.SP11 (was: 1.4.8.SP10) > Message remain in the queue and do not get dispatched > ----------------------------------------------------- > > Key: JBMESSAGING-1684 > URL: https://issues.jboss.org/browse/JBMESSAGING-1684 > Project: JBoss Messaging > Issue Type: Quality Risk > Components: JMS Facade > Affects Versions: 1.4.3.GA > Environment: SuSe Linux Enterprise Server 10, Java 1.5.0_11, AS 5 with JBoss Messaging - default installation > Reporter: Alexander Marktl > Assignee: Yong Hao Gao > Priority: Minor > Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11 > > Attachments: jms-provider-evaluation.zip > > > I tried to create 10 queues and send 10.000 messages per queue from a single producer per queue to a single consumer per queue. Unfortunately not all of the messages where delivered, some messages remain in the queues and wait for delivery. The JMX console for example states: 3 messages in the queue, 3 messages pending for delivery. But nothing happens. My receivers don't get these last messages. I don't know if this is a configuration issue or a bug. > The queues are named: qname_0 ...qname_n -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBMESSAGING-1661) Messages in JBoss 5.1 that use bridging get stuck in a devlivering mode and are not sent to the remote cluster

by Yong Hao Gao (JIRA)

[ https://issues.jboss.org/browse/JBMESSAGING-1661?page=com.atlassian.jira.... ] Yong Hao Gao updated JBMESSAGING-1661: -------------------------------------- Fix Version/s: 1.4.8.SP11 (was: 1.4.8.SP10) > Messages in JBoss 5.1 that use bridging get stuck in a devlivering mode and are not sent to the remote cluster > -------------------------------------------------------------------------------------------------------------- > > Key: JBMESSAGING-1661 > URL: https://issues.jboss.org/browse/JBMESSAGING-1661 > Project: JBoss Messaging > Issue Type: Bug > Affects Versions: 1.4.3.GA > Environment: Linux -- JBoss 5.1 GA / JBM 1.4.3GA / Remoting 2.5.1 > Reporter: Peter Crossley > Assignee: Yong Hao Gao > Fix For: 1.4.8.SP11 > > > A Message bridge between to clusters will get in to a state where the messages will not be picked up by the bridge on the topic/queue and remain in the "delivering" counter until the bridge is restarted via the JMX console or by restarting the Jboss instance. > I attempted to use JBM 1.4.4 which has a fix (JBMESSAGING-1456) that seems to be the same issue, though do to the difference in the remoting I cannot use the 1.4.4 GA release. > Can we get the fixes that were applied to the 1.4.4 release in a usable build for JBoss AS 5.1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBMESSAGING-1648) Bridge may stop working after long time idle

by Yong Hao Gao (JIRA)

[ https://issues.jboss.org/browse/JBMESSAGING-1648?page=com.atlassian.jira.... ] Yong Hao Gao updated JBMESSAGING-1648: -------------------------------------- Fix Version/s: 1.4.8.SP11 (was: 1.4.8.SP10) > Bridge may stop working after long time idle > -------------------------------------------- > > Key: JBMESSAGING-1648 > URL: https://issues.jboss.org/browse/JBMESSAGING-1648 > Project: JBoss Messaging > Issue Type: Bug > Components: JMS Facade > Affects Versions: 1.4.3.GA > Reporter: Yong Hao Gao > Assignee: Yong Hao Gao > Fix For: 1.4.8.SP11 > > > Bridge service may stop working after a long time idle -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBMESSAGING-1718) JMS Queue MessageCount attribute isn't increased on message retrieval

by Yong Hao Gao (JIRA)

[ https://issues.jboss.org/browse/JBMESSAGING-1718?page=com.atlassian.jira.... ] Yong Hao Gao updated JBMESSAGING-1718: -------------------------------------- Fix Version/s: 1.4.8.SP11 (was: 1.4.8.SP10) > JMS Queue MessageCount attribute isn't increased on message retrieval > --------------------------------------------------------------------- > > Key: JBMESSAGING-1718 > URL: https://issues.jboss.org/browse/JBMESSAGING-1718 > Project: JBoss Messaging > Issue Type: Bug > Affects Versions: 1.4.3.GA > Reporter: Richard Opalka > Assignee: Yong Hao Gao > Fix For: 1.4.8.SP11 > > Attachments: jaxws-samples-dar-jms-client.sar, jaxws-samples-dar-jms.jar > > > We're sending JMS message to the queue and are verifying it was received by checking the JMS Queue MessageCount attribute. > This used to work on AS 500, AS 501 and AS 510 but doesn't work on AS trunk and AS Branch_5_x. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBMESSAGING-1707) ConcurrentModificationException in ClientClusteredConnectionFactoryDelegate

by Yong Hao Gao (JIRA)

[ https://issues.jboss.org/browse/JBMESSAGING-1707?page=com.atlassian.jira.... ] Yong Hao Gao updated JBMESSAGING-1707: -------------------------------------- Fix Version/s: 1.4.8.SP11 (was: 1.4.8.SP10) > ConcurrentModificationException in ClientClusteredConnectionFactoryDelegate > --------------------------------------------------------------------------- > > Key: JBMESSAGING-1707 > URL: https://issues.jboss.org/browse/JBMESSAGING-1707 > Project: JBoss Messaging > Issue Type: Quality Risk > Components: JMS Client Manager > Affects Versions: 1.4.3.GA > Reporter: Pavel Slavicek > Assignee: Clebert Suconic > Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11 > > > I have found ConcurrentModificationException in ClientClusteredConnectionFactoryDelegate. > Exception in thread "Thread-11" java.util.ConcurrentModificationException > at java.util.WeakHashMap$HashIterator.nextEntry(WeakHashMap.java:784) > at java.util.WeakHashMap$KeyIterator.next(WeakHashMap.java:817) > at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate$FinalizerShutdownHook.run(ClientClusteredConnectionFactoryDelegate.java:414) > Client: > client with multiple threads, every thread creates-sends-receives-closes. > Problem description: > Problem is in the ClientClusteredConnectionFactoryDelegate.java in the inner class FinalizerShutdownHook. > Shutdown hook implementation should to be written as thread safe (see javadoc for addShutdownHook() method). > Method run() in the FinalizerShutdownHook class iterates over all elements in the registered delegates > but this iteration should be synchronized on the delegates object. > Please see http://java.sun.com/javase/6/docs/api/java/util/Collections.html#synchron... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2014