[jira] Commented: (AMQ-1008) Stomp support for implict creation of temporary destinations: saves server side resources
[ https://issues.apache.org/activemq/browse/AMQ-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37931 ] Sileshi Kassa commented on AMQ-1008: James.Strachan wrote: As for the temporary queue/topic, the JMS[1] spec states that temporary queues/topics may be used by any session using that connection. This seems sensible and should probably be a mechanism embraced by STOMP. If connecting to an ActiveMQ server, then the destinations /temporary/queue/foo, or /queue/temp/foo would be nice. Yeah. I guess the decision needs to be, does the client make up some name and have the broker auto-create it, or should there be an explicit CREATE/DESTROY type verbs on the STOMP protocol. An explicit client request to CREATE temporary queue/topic where the server creates and return via CREATED frame would have been be ideal. One possible server side implementation could associate the temp queue/topic to the session, and automatically deletes it when session ends which is consistent JMS side behavior. I suggested this a while back but the consensus was not to change the stomp protocol, rather extend it for ActiveMQ. Thus, I have proposed a simple temp queue/topic naming convention which doesn't require the Stomp protocol change or extension: destination: /tempqueue/Foo or destination: /temptopic/Bar This temp destination must be globally unique name as in the case of JMS side. And the server somehow associates the temp queue/topic to the session, and deletes it without a client request when the session ends. Mostly a temp queue is created so that it can be used for replyTo. I guess the simplest thing that could possibly work is just to use a naming convention; that /temporary/queue/* (or /tempqueue/*) indicates temporary queues. Though the complication then arises that a client may wish to specify the reply-to destination (more here http://incubator.apache.org/activemq/stomp.html) - which if there was a client side alias (/tempqueue/foo) that would need to get switched to the globally unique queue name. I prefer /tempqueue/Foo, /temptopic/Bar type convention which quite similar to regular queue/topic: /queue/Foo, /topic/Bar I'm not sure how useful the SESSION is; as folks can use a transaction for a session? A stomp connection can be viewed as an implicit session. Having multiple session within a stomp connection may introduce complexity -Sileshi Stomp support for implict creation of temporary destinations: saves server side resources - Key: AMQ-1008 URL: https://issues.apache.org/activemq/browse/AMQ-1008 Project: ActiveMQ Issue Type: Improvement Components: Broker Environment: N/A Reporter: Sileshi Kassa It is quite simple to extend the existing Stomp destination header field and AMQ Stomp server to support a prefix for temporary queue and topic as follows: destination: /tempqueue/a /temptopic/b This does not change the protocol since destination is opaque from the protocol point of view. The semantics of it is left to Stomp server implementation. This will save a lot of server resources from being wasted. For instance with RPC over Stomp implementation, it takes two queues: request queue and reply queue. A reply queue should be a temp queue in this case. I have discussed this on both Stomp dev and AMQ user forums. Here is the link: http://www.nabble.com/Implicit-AMQ-Temp-Queue-and-Topic-creation-support-tf2516578.html -- 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
Re: Release schedule
Is 4.1 released? If not, what is rlelease plans? -Sileshi Hiram Chirino wrote: On 10/4/06, yaussy [EMAIL PROTECTED] wrote: Sorry about that. I'd forgotten about the wireformat stuff. Looks like you can set AMQ 4.1 minimum wire format to 1 and then it will connect to AMQ 4.0.2 (still breaks with AMQ 4.0.1, but 4.0.1 and 4.0.2 work together). This gives me the rollout path we need. Since 4.0.2 has not been officially released, which 4.0.2 versin are you using? RC4 ? I think 4.0.2 RC 4 should be able to connecto the 4.1 without any config changes. A small bug in 4.0 was fixed in 4.0.2 that fixes auto wirefomat versin negociation. Two things though: 1) I could not get multiple connection properties on the TCP connectors, such as tcp://perfgc1a::5112?minmumWireFormatVersion=1connectionTimeout=5000. The XML parser complained. How should this look?? in XML you need replace all the '' with 'amp;' 2) Even with minmumWireFormatVersion=1, will two AMQ 4.1 brokers connect using their newer v2 format? Hum they should. Sees odd that the default is not 1... it should be 1. I'll double check. Thanks for testing this stuff out! yaussy wrote: I put a post in the user forum for this, but thought I'd add something to this thread. I'm concerned about backward compatibility. I've got a test environment with all brokers at 4.0.1, except one I'm upgrading to 4.1. This would be how our production environment would be upgraded - a machine or so at a time. However, the 4.0.1 brokers will not connect to the 4.1 broker, giving the following exception: Exception in thread ActiveMQ Transport: tcp:///170.137.15.160:34695 java.lang.IllegalArgumentException: Invalid version: 2, could not l oad org.apache.activemq.openwire.v2.MarshallerFactory at org.apache.activemq.openwire.OpenWireFormat.setVersion(OpenWireFormat.java:329) at org.apache.activemq.openwire.OpenWireFormat.renegociatWireFormat(OpenWireFormat.java:569) at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:100) at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:122) at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:87) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:143) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.ClassNotFoundException: org.apache.activemq.openwire.v2.MarshallerFactory at org.apache.activemq.util.ClassLoading.loadClass(ClassLoading.java:104) at org.apache.activemq.openwire.OpenWireFormat.setVersion(OpenWireFormat.java:327) ... 6 more There must be an upgrade path for 4.1. If that means I have to go to 4.0.2 (which I did not try yet), that is OK. But, I can't possibly tell my management that I have to upgrade the AMQ version on all 50 or so machines we have in production. Hiram Chirino wrote: I'm starting to work on the first release candidate for 4.1.. please let me know if I should hold off! On 10/3/06, Vadim Pesochinsky [EMAIL PROTECTED] wrote: Hi James, It looks like this is changed now with 4.0.3. Any idea when 4.1 is going to be out? Thanks. -- View this message in context: http://www.nabble.com/Release-schedule-tf2124265.html#a6630219 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- Regards, Hiram Blog: http://hiramchirino.com -- View this message in context: http://www.nabble.com/Release-schedule-tf2124265.html#a6647640 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- Regards, Hiram Blog: http://hiramchirino.com -- View this message in context: http://www.nabble.com/Release-schedule-tf2124265.html#a7935126 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
[jira] Created: (AMQ-1008) Stomp support for implict creation of temporary destinations: saves server side resources
Stomp support for implict creation of temporary destinations: saves server side resources - Key: AMQ-1008 URL: https://issues.apache.org/activemq/browse/AMQ-1008 Project: ActiveMQ Issue Type: Improvement Components: Broker Environment: N/A Reporter: Sileshi Kassa It is quite simple to extend the existing Stomp destination header field and AMQ Stomp server to support a prefix for temporary queue and topic as follows: destination: /tempqueue/a /temptopic/b This does not change the protocol since destination is opaque from the protocol point of view. The semantics of it is left to Stomp server implementation. This will save a lot of server resources from being wasted. For instance with RPC over Stomp implementation, it takes two queues: request queue and reply queue. A reply queue should be a temp queue in this case. I have discussed this on both Stomp dev and AMQ user forums. Here is the link: http://www.nabble.com/Implicit-AMQ-Temp-Queue-and-Topic-creation-support-tf2516578.html -- 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] Closed: (AMQ-978) No Messaged delivery when mixing Perl stomp client Producer/Consumer and Java JMS Producer/Consumer
[ https://issues.apache.org/activemq/browse/AMQ-978?page=all ] Sileshi Kassa closed AMQ-978. - Resolution: Won't Fix This is not ActiveMQ problem as such. This is more of the Perl Net::Stomp package dealing with binary data reading. No Messaged delivery when mixing Perl stomp client Producer/Consumer and Java JMS Producer/Consumer --- Key: AMQ-978 URL: https://issues.apache.org/activemq/browse/AMQ-978 Project: ActiveMQ Issue Type: Bug Components: Connector Environment: This problem seems platform independent: It happens in Linux, Mac OSX, and Windows. Software Used: ActiveMQ 4.0, Java 5.0, JMS, Perl 5.8.7, Perl CPAN module Net-Stomp-0.31 Reporter: Sileshi Kassa Attachments: Publisher.pl, Subscriber.pl Facts: Perl Stomp client Producer and Consumer works fine Java JMS client Producer and Consumer works fine I have also used other Perl Stomp protocol implementation with no problem. The problem happens when I mix Java and Perl clients Scenario Test 1: A. Perl Stomp client Consumer B. Java JMS client Producer Scenario Test 2: A. Java JMS client Consumer B. Perl Stomp client Producer I have looked into it via Java JMX management jconsole, and it seems to me there is a wall between the stomp server and default server. It the stomp server only passes messages coming from stomp lients and default server also does the same. If this is truly the case, and this is by design, I will be very disappointed. There should not be any wall. A message is message irrespective of its source and should be delivered to any one that is listening on the same destination. I will attach the Perl clients testcases. For Java client, a simple JMS client Producer and Consumer with the same topic used as the perl side will do the job. The topic I used on the perl side: /topic/Test.CrossDelivery and the Java side topic is Test.CrossDelivery This problem is a show stopper for us. -- 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-978) No Messaged delivery when mixing Perl stomp client Producer/Consumer and Java JMS Producer/Consumer
No Messaged delivery when mixing Perl stomp client Producer/Consumer and Java JMS Producer/Consumer --- Key: AMQ-978 URL: https://issues.apache.org/activemq/browse/AMQ-978 Project: ActiveMQ Issue Type: Bug Components: Connector Environment: This problem seems platform independent: It happens in Linux, Mac OSX, and Windows. Software Used: ActiveMQ 4.0, Java 5.0, JMS, Perl 5.8.7, Perl CPAN module Net-Stomp-0.31 Reporter: Sileshi Kassa Attachments: Publisher.pl, Subscriber.pl Facts: Perl Stomp client Producer and Consumer works fine Java JMS client Producer and Consumer works fine I have also used other Perl Stomp protocol implementation with no problem. The problem happens when I mix Java and Perl clients Scenario Test 1: A. Perl Stomp client Consumer B. Java JMS client Producer Scenario Test 2: A. Java JMS client Consumer B. Perl Stomp client Producer I have looked into it via Java JMX management jconsole, and it seems to me there is a wall between the stomp server and default server. It the stomp server only passes messages coming from stomp lients and default server also does the same. If this is truly the case, and this is by design, I will be very disappointed. There should not be any wall. A message is message irrespective of its source and should be delivered to any one that is listening on the same destination. I will attach the Perl clients testcases. For Java client, a simple JMS client Producer and Consumer with the same topic used as the perl side will do the job. The topic I used on the perl side: /topic/Test.CrossDelivery and the Java side topic is Test.CrossDelivery This problem is a show stopper for us. -- 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
