New refactored STOMP implementation.
Howdy STOMP developers, Just wantted to let you know that I spent the day doing some major refactoring to the STOMP server side protocol implementation in ActiveMQ. The previous implementation did all the work inside a WireFormat layer. The poll model that it imposed made some things difficult to do and made the code just ugly. I refactored it so that StompWireFormat takes the STOMP frames and produces StompCommand objects which are like a 1:1 mapping (Perhaps I should rename that to StompFrame). Then the stomp transport factory sets up the TcpTransport to be filtered by a StompTransportFilter which converts the StompCommand/Protocol into the ActiveMQ commands and Protocol. Since the Transport is more event based and is also aware of the transport lifecycle, it should let us continue to extend and add more features to the STOMP protocol easier. I implemented this in a new package so that we can easily switch back to the old implementation if needed. Out of the box we are now using the new implementation. But I'd like to get some feed back to see if it introduced any new bugs or if it fixed any old bugs. If all goes well, I'll get rid of the old version soon. -- Regards, Hiram Blog: http://hiramchirino.com
[jira] Commented: (AMQ-725) Messages Sent by JMS that contain header properties cause error when STOMP client registers a Subscriber
[ https://issues.apache.org/activemq/browse/AMQ-725?page=comments#action_36492 ] William MacDonald commented on AMQ-725: --- I have tested this with the new 4.01 release of ActiveMQ using the default configuration file and I am still having the problem. After performing a TCP connections to the Broker on the listener defined as tcp://wrpkmnb:61613?wireFormat=stomp: I transmit the connection message: CONNECT\010login:billm\010passcode:billm\010client-id:webProcessor\010\010\000 After which I receive the message: CONNECTED\010session:webProcessor\010\010\000\010 I then try to subscribe to a queue: SUBSCRIBE\010destination:/queue/WebRequest\010id:webProcessorconsumer:2\010ack:client\010activemq.prefetchSize:1\010\010\000 And no response is returned from the Broker but the log shows the following message. Exception in thread "ActiveMQ Connection Dispatcher: 28939486" java.lang.NullPointerException at java.util.Hashtable.put(Unknown Source) at java.util.Hashtable.putAll(Unknown Source) at org.apache.activemq.transport.stomp.FrameBuilder.addHeaders(FrameBuilder.java:65) at org.apache.activemq.transport.stomp.Subscription.receive(Subscription.java:76) at org.apache.activemq.transport.stomp.StompWireFormat.writeCommand(StompWireFormat.java:154) at org.apache.activemq.transport.stomp.StompWireFormat.marshal(StompWireFormat.java:305) at org.apache.activemq.transport.tcp.TcpTransport.oneway(TcpTransport.java:124) at org.apache.activemq.transport.InactivityMonitor.oneway(InactivityMonitor.java:141) at org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44) at org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60) at org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:211) at org.apache.activemq.broker.AbstractConnection.processDispatch(AbstractConnection.java:581) at org.apache.activemq.broker.AbstractConnection.iterate(AbstractConnection.java:597) at org.apache.activemq.thread.DedicatedTaskRunner.runTask(DedicatedTaskRunner.java:87) at org.apache.activemq.thread.DedicatedTaskRunner.access$000(DedicatedTaskRunner.java:24) at org.apache.activemq.thread.DedicatedTaskRunner$1.run(DedicatedTaskRunner.java:38) For readability I have replaced the linefeeds with \010 and the nulls with \000 representations. > Messages Sent by JMS that contain header properties cause error when STOMP > client registers a Subscriber > > > Key: AMQ-725 > URL: https://issues.apache.org/activemq/browse/AMQ-725 > Project: ActiveMQ > Type: Bug > Components: Transport > Versions: 4.0 > Environment: Running on WinXP with Sun JDK1.5.0_06 > Reporter: William MacDonald > Assignee: Hiram Chirino > Priority: Blocker > Fix For: 4.1, 4.0.2 > > > I am using the lastest 4.0 release build of ActiveMQ and I have been trying > to produce messages in a JMS client and receive the messages in a STOMP > client. > What I have found is that if the JMS Client adds header properties to the > message to be delivered to ActiveMQ then when I subscribe with the STOMP > client I am receiving the Error listed below. If I remove all header > properties then the message is transmitted correctly. I have also found that > if I send messages with a STOMP client that has header properties then > everything works correctly. > java.lang.NullPointerException > at java.util.Hashtable.put(Unknown Source) > at java.util.Hashtable.putAll(Unknown Source) > at > org.apache.activemq.transport.stomp.FrameBuilder.addHeaders(FrameBuilder.java:65) > at > org.apache.activemq.transport.stomp.Subscription.receive(Subscription.java:76) > at > org.apache.activemq.transport.stomp.StompWireFormat.writeCommand(StompWireFormat.java:154) > at > org.apache.activemq.transport.stomp.StompWireFormat.marshal(StompWireFormat.java:305) > at > org.apache.activemq.transport.tcp.TcpTransport.oneway(TcpTransport.java:124) > at > org.apache.activemq.transport.InactivityMonitor.oneway(InactivityMonitor.java:141) > at org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44) > at > org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60) > at > org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:211) > at > org.apache.activemq.broker.AbstractConnection.processDispatch(AbstractConnection.java:581) > at > org.apache.activemq.broker.AbstractConnection.iterate(AbstractConnection.java:597) > at > org.apache.activemq.thread.DedicatedTaskRunner.runTask(DedicatedTaskRunner.java:87) > at > org.apache.activemq.thread.DedicatedTaskRunner.access$000(DedicatedTaskRunner.java:24) > at > org.apache.activemq.thread.DedicatedTaskRunner$1.run(DedicatedTaskRunner.java:38)
[jira] Updated: (AMQ-528) 4.0 M4 NullPointerException while shutting down
[ https://issues.apache.org/activemq/browse/AMQ-528?page=all ] Hiram Chirino updated AMQ-528: -- Fix Version: 4.0.2 4.1 (was: 4.0 RC2) Version: 4.0 (was: 4.0 M4) Ajusted target fix version so that it shows up on the roadmap right. > 4.0 M4 NullPointerException while shutting down > --- > > Key: AMQ-528 > URL: https://issues.apache.org/activemq/browse/AMQ-528 > Project: ActiveMQ > Type: Bug > Versions: 4.0 > Environment: RedHat Linux Enterprise Server 3, Tomcat 5.5.15, MySQL 5.0.18 > for Linux > Reporter: Leon Hu > Priority: Critical > Fix For: 4.1, 4.0.2 > > > Setup: > 3 networked brokers, B1, B2, and B3, on 3 servers, connected using multicast > discovery. activemq.xml: > > > > dataSource="#mysql-ds"/> > > > > discoveryUri="multicast://default"/> > > > > > > > > > destroy-method="close"> > > value="jdbc:mysql://localhost/activemq?relaxAutoCommit=true"/> > > > > > Similar for B2 and B3. > Two queues: Q1 and Q2. > Two producers, one for each queue, both producers connected to B1. > One Q1 cosumer connected to B1, another Q1 consumer on B2. > One Q2 consumer connected to B2, another Q2 consumer connected to B3. > Steps: > Start the brokers and start sending messages to the queue. > After a while, stop the brokers (Sequence does not matter) > See the errors in catalina.out of the Tomcat that has a broker with both > producers and consumers connected > The problems: > 1. > Exception in thread "ActiveMQ Scheduler" java.lang.NullPointerException > at > edu.emory.mathcs.backport.java.util.concurrent.helpers.Utils$SunPerfProvider.nanoTime(Utils.java:219) > at > edu.emory.mathcs.backport.java.util.concurrent.helpers.Utils.nanoTime(Utils.java:99) > at > edu.emory.mathcs.backport.java.util.concurrent.ScheduledThreadPoolExecutor.now(ScheduledThreadPoolExecutor.java:88) > at > edu.emory.mathcs.backport.java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.getDelay(ScheduledThreadPoolExecutor.java:137) > Exception in thread "ActiveMQ Scheduler" Exception in thread "ActiveMQ > Scheduler" Exception in thread "ActiveMQ Scheduler" at > edu.emory.mathcs.backport.java.util.concurrent.DelayQueue.take(DelayQueue.java:154) > at > edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:470) > at > edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:667) > at java.lang.Thread.run(Thread.java:595) > java.lang.NullPointerException > at > edu.emory.mathcs.backport.java.util.concurrent.helpers.Utils$SunPerfProvider.nanoTime(Utils.java:219) > Exception in thread "ActiveMQ Scheduler" Exception in thread "ActiveMQ > Scheduler" Exception in thread "ActiveMQ Scheduler" at > edu.emory.mathcs.backport.java.util.concurrent.helpers.Utils.nanoTime(Utils.java:99) > at > edu.emory.mathcs.backport.java.util.concurrent.ScheduledThreadPoolExecutor.now(ScheduledThreadPoolExecutor.java:88) > at > edu.emory.mathcs.backport.java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.getDelay(ScheduledThreadPoolExecutor.java:137) > at > edu.emory.mathcs.backport.java.util.concurrent.DelayQueue.take(DelayQueue.java:154) > at > edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:470) > Exception in thread "ActiveMQ Scheduler" Exception in thread "ActiveMQ > Scheduler" at > edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:667) > at java.lang.Thread.run(Thread.java:595) > 2. The same exception is logged to the log file (in my case catalina.out) for > hundreds of times, resulting a log file exceeding 150 MB in 2 minutes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-608) Change logging level of some DemandForwardingBridge log messages.
[ https://issues.apache.org/activemq/browse/AMQ-608?page=all ] Hiram Chirino updated AMQ-608: -- Fix Version: 4.0.2 (was: 4.0.1) > Change logging level of some DemandForwardingBridge log messages. > - > > Key: AMQ-608 > URL: https://issues.apache.org/activemq/browse/AMQ-608 > Project: ActiveMQ > Type: Improvement > Components: Broker > Versions: 4.0 > Reporter: Kevin Yaussy > Assignee: Hiram Chirino > Fix For: 4.1, 4.0.2 > Attachments: DemandForwardingBridge.java, > DemandForwardingBridgeSupport.java, DemandForwardingBridgeSupport.patch, > FailoverTransport.java, FailoverTransport.java, FailoverTransport.patch, > InactivityMonitor.patch, InactivityMonitor.patch2 > > > In DemandForwardingBridge, I'd like to be able to see subscription messages > (and unsubscription messages), but not "bridging" messages. Both classes of > log messages are log.trace. Seems like the "bridging" messages should remain > trace, as you would want to look at that when you are doing pretty detailed > debugging. However, I'd like to see subscribe/unsubscribe messages all the > time. If those could be either info or debug, that would allow me to turn > those on separately. I realize that I can see what is currently subscribed > via the JMX console. However, seeing the subscribe/unsubscribe messages will > allow diagnostics over time - who subscribed when type of questions. > Mainly, I'm referring to messages logged as trace in: > DemandForwardingBridge.serviceRemoteConsumerAdvisory > DemandForwardingBridge.removeDemandSubscription -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-789) WireFormatNegotiator could hang a client or server connection if the peer disconnects before sending the wire format info
[ https://issues.apache.org/activemq/browse/AMQ-789?page=all ] Hiram Chirino resolved AMQ-789: --- Resolution: Fixed Fix in trunk revision 418497 We now wait up to 15 seconds before timeing out the wireformat negociation phase. > WireFormatNegotiator could hang a client or server connection if the peer > disconnects before sending the wire format info > - > > Key: AMQ-789 > URL: https://issues.apache.org/activemq/browse/AMQ-789 > Project: ActiveMQ > Type: Bug > Versions: 4.0 > Reporter: Hiram Chirino > Assignee: Hiram Chirino > Fix For: 4.1 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-789) WireFormatNegotiator could hang a client or server connection if the peer disconnects before sending the wire format info
WireFormatNegotiator could hang a client or server connection if the peer disconnects before sending the wire format info - Key: AMQ-789 URL: https://issues.apache.org/activemq/browse/AMQ-789 Project: ActiveMQ Type: Bug Versions: 4.0 Reporter: Hiram Chirino Assigned to: Hiram Chirino Fix For: 4.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-451) allow scheduled delivery of messages
[ https://issues.apache.org/activemq/browse/AMQ-451?page=all ] Hiram Chirino updated AMQ-451: -- Fix Version: 4.2 (was: 4.1) scheduling delivery of messages is very similar to expiring messages on a given date. Lets thing about how to do this for the 4.2 release. > allow scheduled delivery of messages > > > Key: AMQ-451 > URL: https://issues.apache.org/activemq/browse/AMQ-451 > Project: ActiveMQ > Type: New Feature > Reporter: james strachan > Fix For: 4.2 > > > rather than be dispatched immediately it would be good to support a custom > header to indicate the delivery some time in the future. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-406) enable the configuration of prefetch policies in the JNDI configuration file by allowing the prefetch values to be visible as properties on ActiveMQConnectionFactory
[ https://issues.apache.org/activemq/browse/AMQ-406?page=comments#action_36488 ] Hiram Chirino commented on AMQ-406: --- Fixed in trunk rev 418495. You can now configure the prefetchPolicy and redeliveryPolicy using the jndi properties. For example: properties.put(Context.INITIAL_CONTEXT_FACTORY, "org.apache.activemq.jndi.ActiveMQInitialContextFactory"); properties.put(Context.PROVIDER_URL, "tcp://localhost:65432"); properties.put("prefetchPolicy.queuePrefetch", "777"); properties.put("redeliveryPolicy.maximumRedeliveries", "15"); properties.put("redeliveryPolicy.backOffMultiplier", "32"); InitialContext context = new InitialContext(properties); You can also do it using the Broker URL: new ActiveMQConnectionFactory("tcp://localhost:61616?jms.redeliveryPolicy.maximumRedeliveries=15"); > enable the configuration of prefetch policies in the JNDI configuration file > by allowing the prefetch values to be visible as properties on > ActiveMQConnectionFactory > - > > Key: AMQ-406 > URL: https://issues.apache.org/activemq/browse/AMQ-406 > Project: ActiveMQ > Type: Improvement > Reporter: james strachan > Fix For: 4.1 > > > if we delegate all the properties on PrefetchPolicy as basisc properties on > ActiveMQConnectionFactory we can configue the values in JNDI. e.g. in > jndi.properties > ConnectionFactory.queuePrefetch = 100 > which would call ActiveMQConnectionFactory.setQueuePrefetch(100) => > prefetchPolicy.setQueuePrefetch(100) etc -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-406) enable the configuration of prefetch policies in the JNDI configuration file by allowing the prefetch values to be visible as properties on ActiveMQConnectionFactory
[ https://issues.apache.org/activemq/browse/AMQ-406?page=all ] Hiram Chirino resolved AMQ-406: --- Resolution: Fixed > enable the configuration of prefetch policies in the JNDI configuration file > by allowing the prefetch values to be visible as properties on > ActiveMQConnectionFactory > - > > Key: AMQ-406 > URL: https://issues.apache.org/activemq/browse/AMQ-406 > Project: ActiveMQ > Type: Improvement > Reporter: james strachan > Fix For: 4.1 > > > if we delegate all the properties on PrefetchPolicy as basisc properties on > ActiveMQConnectionFactory we can configue the values in JNDI. e.g. in > jndi.properties > ConnectionFactory.queuePrefetch = 100 > which would call ActiveMQConnectionFactory.setQueuePrefetch(100) => > prefetchPolicy.setQueuePrefetch(100) etc -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-406) enable the configuration of prefetch policies in the JNDI configuration file by allowing the prefetch values to be visible as properties on ActiveMQConnectionFactory
[ https://issues.apache.org/activemq/browse/AMQ-406?page=all ] Hiram Chirino reassigned AMQ-406: - Assign To: Hiram Chirino > enable the configuration of prefetch policies in the JNDI configuration file > by allowing the prefetch values to be visible as properties on > ActiveMQConnectionFactory > - > > Key: AMQ-406 > URL: https://issues.apache.org/activemq/browse/AMQ-406 > Project: ActiveMQ > Type: Improvement > Reporter: james strachan > Assignee: Hiram Chirino > Fix For: 4.1 > > > if we delegate all the properties on PrefetchPolicy as basisc properties on > ActiveMQConnectionFactory we can configue the values in JNDI. e.g. in > jndi.properties > ConnectionFactory.queuePrefetch = 100 > which would call ActiveMQConnectionFactory.setQueuePrefetch(100) => > prefetchPolicy.setQueuePrefetch(100) etc -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-450) expired messages should be sent to some kind of dead letter queue
[ https://issues.apache.org/activemq/browse/AMQ-450?page=all ] Hiram Chirino updated AMQ-450: -- Fix Version: 4.2 (was: 4.1) Description: This could take a little bit of work reorganizing how the broker and the persistence store opperate. Targeting for 4.2 > expired messages should be sent to some kind of dead letter queue > - > > Key: AMQ-450 > URL: https://issues.apache.org/activemq/browse/AMQ-450 > Project: ActiveMQ > Type: Improvement > Components: Broker > Versions: 4.0 > Reporter: james strachan > Assignee: Hiram Chirino > Fix For: 4.2 > > > This could take a little bit of work reorganizing how the broker and the > persistence store opperate. Targeting for 4.2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-340) allow topics in particular but also queues to have a 'namespace URI' like WS-Notification
[ https://issues.apache.org/activemq/browse/AMQ-340?page=comments#action_36487 ] Hiram Chirino commented on AMQ-340: --- Hi James, Could give a few exmples of what you mean? > allow topics in particular but also queues to have a 'namespace URI' like > WS-Notification > - > > Key: AMQ-340 > URL: https://issues.apache.org/activemq/browse/AMQ-340 > Project: ActiveMQ > Type: New Feature > Reporter: james strachan > Fix For: 4.1 > > > This would allow a real clean mapping from WS-N topics and ActiveMQ at the > protocol level. We could use the namespace as a level of indirection to map > to a broker, a cluster of brokers or even a particular area of a network etc. > The namespace could be a broker's name too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira