August 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-1553) Heuristic XA Support

by Clebert Suconic (JIRA)

Heuristic XA Support -------------------- Key: JBMESSAGING-1553 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1553 Project: JBoss Messaging Issue Type: Feature Request Reporter: Clebert Suconic Assignee: Clebert Suconic Fix For: 2.0.0.CR1 -- 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, 8 months

2
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1695) JMSServerControl.createQueue() fails when there are any paged messages for the Queue

by Bijith Kumar (JIRA)

JMSServerControl.createQueue() fails when there are any paged messages for the Queue ------------------------------------------------------------------------------------ Key: JBMESSAGING-1695 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1695 Project: JBoss Messaging Issue Type: Bug Affects Versions: 2.0.0.beta4 Environment: Windows Vista 32 bit 2GB RAM Reporter: Bijith Kumar Assignee: Tim Fox Hi, I am using JMSServerControl.createQueue() to create queues on the fly (programatically) as discussed in http://www.jboss.org/index.html?module=bb&op=viewtopic&t=157444. This works fine and the API creates the Queue or just binds the queue to JNDI if queue already exists. However, this fails as soon as there are any messages paged in the Queue. i.e. If I am trying to use this API for a Queue which already exists and has some messages paged, subsequent calls to this API fails with following Exception. Test file is attached. [code]java.lang.Exception: did not receive reply for message org.jboss.messaging.core.client.impl.ClientMessageImpl@18e613d at org.jboss.messaging.core.management.impl.ReplicationOperationInvokerImpl.invoke(ReplicationOperationInvokerImpl.java:115) at org.jboss.messaging.core.management.jmx.impl.ReplicationAwareStandardMBeanWrapper.replicationAwareInvoke(ReplicationAwareStandardMBeanWrapper.java:75) at org.jboss.messaging.jms.server.management.jmx.impl.ReplicationAwareJMSServerControlWrapper.createQueue(ReplicationAwareJMSServerControlWrapper.java:499) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.sun.jmx.mbeanserver.StandardMetaDataImpl.invoke(StandardMetaDataImpl.java:414) at javax.management.StandardMBean.invoke(StandardMBean.java:323) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1410) at javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectionImpl.java:81) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1247) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1343) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:784) at sun.reflect.GeneratedMethodAccessor27.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) at sun.rmi.transport.Transport$1.run(Transport.java:153) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:149) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707) at java.lang.Thread.run(Thread.java:595)[/code] -- 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, 8 months

3
9
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1671) Consider storing JMS destinations in their own journal instance

by Tim Fox (JIRA)

Consider storing JMS destinations in their own journal instance --------------------------------------------------------------- Key: JBMESSAGING-1671 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1671 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assignee: Tim Fox Fix For: 2.0.0 We should consider storing JMS destinations in their own journal instance, and automatically deploy them into JNDI and management from this. This would mean that any JMS destinations created via the management interface would get redeployed on startup, which is not currently the case -- 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, 8 months

2
2
0 / 0

[JBoss JIRA] Updated: (JBMESSAGING-375) Grouping of messages

by Tim Fox (JIRA)

[ https://jira.jboss.org/jira/browse/JBMESSAGING-375?page=com.atlassian.jir... ] Tim Fox updated JBMESSAGING-375: -------------------------------- Fix Version/s: 2.0.0 (was: 2.0.0.beta5) > Grouping of messages > -------------------- > > Key: JBMESSAGING-375 > URL: https://jira.jboss.org/jira/browse/JBMESSAGING-375 > Project: JBoss Messaging > Issue Type: Feature Request > Reporter: Tim Fox > Assignee: Andy Taylor > Fix For: 2.0.0 > > Attachments: jbmessaging-375.patch, patch-JBMESSAGING-375.txt, patch-JBMESSAGING-375.txt > > Original Estimate: 1 week > Remaining Estimate: 1 week > > We should add an ability to group messages by a group id so any messages with the same group id always go to the same consumer on a queue. > This would be useful when having competing consumers on a queue and you want each consumer to handle all messages with a particular value of group id. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1090) Add appropriate Exception handling when hitting MaxSize

by Jay Howell (JIRA)

Add appropriate Exception handling when hitting MaxSize ------------------------------------------------------- Key: JBMESSAGING-1090 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1090 Project: JBoss Messaging Issue Type: Bug Components: Messaging Core Affects Versions: 1.4.0.GA Reporter: Jay Howell Assigned To: Tim Fox When using MaxSize for a queue and topic the following behaviors exist Queue - When a queue hits MaxSize, the delivery returned in Channel Support is null. This triggers a very generic JMSException to be thrown by looking at the delivery and seeing if it's null in the ServerConnectionEndpoint. Topic - When a subscription hits the MaxSize(defined in the topic), the delivery returned will be null, but no check is done and no JMSException is thrown in the ServerConnectionEndpoint. What this means is that anyone who wants to put hooks in to gather the messages dropped can't. Either because the exception is too generic or because one is not thrown at all. I would purpose that we put proper exception handling down in the ChannelSupport where MaxSize is checked for both queues and subscriptions. We would need to Change the The two methods in channel support for send and sendInternal to throw a JMSException. Then we throw a checked Exception in ChannelSupport for MaxSize violations(make a new exception derived from MessagingJMSException). Adding proper exception handling to these would allow users to add aspects and notifications when messages are dropped due to MaxSize. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

4
17
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1424) Provider strict message ordering via "ordering groups"

by Tim Fox (JIRA)

Provider strict message ordering via "ordering groups" ------------------------------------------------------ Key: JBMESSAGING-1424 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1424 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assignee: Tim Fox Fix For: 2.0.0 Beta See linked task -- 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, 8 months

2
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1635) Refactor HA-JNDI example to provide a real clustering test

by Jeff Mesnil (JIRA)

Refactor HA-JNDI example to provide a real clustering test ---------------------------------------------------------- Key: JBMESSAGING-1635 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1635 Project: JBoss Messaging Issue Type: Task Reporter: Jeff Mesnil Assignee: Tim Fox Fix For: 2.0.0.CR1 our current javaee/hajndi does nothing (apart from opening connections) the example should be enhanced to demonstrate clustering feature *and* should be better automated (wrt to deployment and server starts/stops) -- 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, 8 months

3
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1149) Singleton consumer on queue/topic

by Tim Fox (JIRA)

Singleton consumer on queue/topic --------------------------------- Key: JBMESSAGING-1149 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1149 Project: JBoss Messaging Issue Type: Feature Request Affects Versions: 1.4.0.SP1 Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.4.0.SP2 A last minute requirement came up from the AS team (Carlo and Bill DeCoste). JBoss MQ uses HA singleton to provide a singleton consumer on a queue/topic. If that node fails, the consumer should failover onto another single node. Currently this isn't supported in JBM. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

2
10
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1675) add netty servlet firewall support when available.

by Andy Taylor (JIRA)

add netty servlet firewall support when available. -------------------------------------------------- Key: JBMESSAGING-1675 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1675 Project: JBoss Messaging Issue Type: Task Affects Versions: 2.0.0.beta3 Reporter: Andy Taylor Assignee: Andy Taylor Fix For: 2.0.0 -- 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, 8 months

3
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1400) Allow users to configure a system wide maximum connection limit

by Jay Howell (JIRA)

Allow users to configure a system wide maximum connection limit --------------------------------------------------------------- Key: JBMESSAGING-1400 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1400 Project: JBoss Messaging Issue Type: Feature Request Reporter: Jay Howell Assignee: Tim Fox Fix For: 2.0.0. GA Many users are complaining of errors that say "Too many open files", which comes from the number of sockets open during jms processing. It's currently possible to run the system out of resources. We currently only have control of this through the remoting/netty/mina layer. We should have a setting in JBM that limits the number of connections systemwide, that is independent of the remoting protocol/package. This way users wouldn't have to keep learning a new package/configuration setting each time the communications package changes in jbm. -- 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, 8 months

3
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2009