Re: [activemq-user] Queue and Persistence for CMS
Hi James.Strachan, I am working cms(ActiveMQ-4.0) code on SuSe(Linux machine- i686-suse-linux, version 2.6.13-15.8-default) You refer me to use Queue to mentain the persistence in the cms code, but this is Outstanding Item http://svn.apache.org/repos/asf/incubator/activemq/trunk/cms/docs/cms_overvi ew.pdf)according to the documentation. If it is under developing by the ActiveMQ team, then my I ask you when it will develope because my work is delaying. If you have any other option to maintain the persistence Please refere me so that I can start my work. Thanks in advance Regards Arashad Ahamad
[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] 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] 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] 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-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] 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: broker useJmx=false brokerName=B1 persistenceAdapter journaledJDBC journalLogFiles=5 dataDirectory=foo dataSource=#mysql-ds/ /persistenceAdapter transportConnectors transportConnector uri=tcp://localhost:61616 discoveryUri=multicast://default/ /transportConnectors networkConnectors networkConnector uri=multicast://default/ /networkConnectors /broker bean id=mysql-ds class=org.apache.commons.dbcp.BasicDataSource destroy-method=close property name=driverClassName value=com.mysql.jdbc.Driver/ property name=url value=jdbc:mysql://localhost/activemq?relaxAutoCommit=true/ property name=username value=activemqUser/ property name=password value=activemqPwd/ property name=poolPreparedStatements value=true/ /bean 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] 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) -- This message is automatically generated by JIRA. -
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
