August 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-1401) Unverified: Restarting a Queue will delete persistent messages in the queue.

by Jay Howell (JIRA)

Unverified: Restarting a Queue will delete persistent messages in the queue. ---------------------------------------------------------------------------- Key: JBMESSAGING-1401 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1401 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.4.0.SP3 Reporter: Jay Howell Assignee: Tim Fox Restarting a queue in a running server will delete persistent messages out of the database. This bug was found while troubleshooting a case. When a customer restarted the queues, they noticed that all of the persistent messages in the database were gone. I have yet to verify this and will verify as soon as possible. I wanted to make sure that I didn't forget to put it in. So at this point this is an unverified bug. -- 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

12 years, 3 months

5
20
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1594) Provide support for a List of Strings (in StreamMessage) with a size > 64K

by Colin Mondesir (JIRA)

Provide support for a List of Strings (in StreamMessage) with a size > 64K -------------------------------------------------------------------------- Key: JBMESSAGING-1594 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1594 Project: JBoss Messaging Issue Type: Feature Request Components: Messaging Core Affects Versions: 1.4.0.SP3 Reporter: Colin Mondesir Assignee: Tim Fox Looking at the code, there is support for 'longstring' for java.lang.String. But that doesn't happen for a List of Strings. -- 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

12 years, 3 months

4
20
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1517) Malformed HTTP POST from Post Office management page in JMX Console

by Paul Kaiser (JIRA)

Malformed HTTP POST from Post Office management page in JMX Console ------------------------------------------------------------------- Key: JBMESSAGING-1517 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1517 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.4.0.SP3_CP03 Environment: All Reporter: Paul Kaiser Assignee: Tim Fox When trying to submit changes to the configuration of the Messaging Post Office from the JMX Console interface, the improper quoting of configuration strings results in an improper HTTP POST. This prevents the submission of any updates to the component. -- 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

12 years, 3 months

4
24
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1513) Database maintenance scripts

by Len DiMaggio (JIRA)

Database maintenance scripts ---------------------------- Key: JBMESSAGING-1513 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1513 Project: JBoss Messaging Issue Type: Feature Request Components: Configuration and Management Affects Versions: 1.4.2.GA.SP1 Reporter: Len DiMaggio Assignee: Tim Fox Project JIRA for SOA-P platform JIRA: https://jira.jboss.org/jira/browse/SOA-310 -- 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

12 years, 3 months

4
20
0 / 0

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

by Colin Mondesir (JIRA)

Programmatic to check the state of a topic ------------------------------------------ Key: JBMESSAGING-1615 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1615 Project: JBoss Messaging Issue Type: Feature Request Affects Versions: 1.4.1.GA Reporter: Colin Mondesir Assignee: Howard Gao Priority: Minor 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 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

12 years, 3 months

5
22
0 / 0

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

by Emanuel Muckenhuber (JIRA)

expose jbossInternalLifecycle method on jms destination mbeans -------------------------------------------------------------- Key: JBMESSAGING-1610 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1610 Project: JBoss Messaging Issue Type: Task Components: AS Integration Affects Versions: 1.4.3.GA Reporter: Emanuel Muckenhuber Assignee: Tim Fox 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 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

12 years, 3 months

4
20
0 / 0

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

by Dennis Reed (JIRA)

add example TCP cluster configuration ------------------------------------- Key: JBMESSAGING-1619 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1619 Project: JBoss Messaging Issue Type: Bug Components: JMS Clustering Affects Versions: 1.4.0.SP3.CP07 Reporter: Dennis Reed Assignee: Tim Fox 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 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

12 years, 3 months

4
22
0 / 0

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

by Howard Gao (JIRA)

Bridge may stop working after long time idle -------------------------------------------- Key: JBMESSAGING-1648 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1648 Project: JBoss Messaging Issue Type: Bug Components: JMS Facade Affects Versions: 1.4.3.GA Reporter: Howard Gao Assignee: Howard Gao Fix For: 1.4.5.GA Bridge service may stop working after a long time idle -- 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

12 years, 3 months

3
13
0 / 0

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

by Victor Starenky (JIRA)

Messages are piling up in the queues in clustered environment and not pulled by message sucker ---------------------------------------------------------------------------------------------- Key: JBMESSAGING-1631 URL: https://jira.jboss.org/jira/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: Tim Fox 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 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

12 years, 3 months

6
37
0 / 0

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

by Yusuke Yamamoto (JIRA)

Provide complete message ordering in a clustered environment ------------------------------------------------------------ Key: JBMESSAGING-1621 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1621 Project: JBoss Messaging Issue Type: Feature Request Reporter: Yusuke Yamamoto Assignee: Tim Fox 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 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

12 years, 3 months

5
22
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2011