[jira] [Commented] (QPID-3838) [JMS] Vendor specific properties should be prefixed with JMS_
[ https://issues.apache.org/jira/browse/QPID-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13207335#comment-13207335 ] Rajith Attapattu commented on QPID-3838: Simply changing the existing behaviour can break existing applications. One solution is to check the "strict-jms" flag and convert the property name to allow the TCK to pass. i.e if the flag is present, "qpid.subject" will be converted to "JMS_qpid.subject". (This is done on the receiving side, so nothing would change on the wire) Applications could still continue to use "qpid.subject" to retrieve the subject and the code internally will resolve to "JMS_qpid.subject". Perhaps there is a more elegant way to solve this issue. Comments are welcome ! > [JMS] Vendor specific properties should be prefixed with JMS_ > - > > Key: QPID-3838 > URL: https://issues.apache.org/jira/browse/QPID-3838 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.12, 0.14 >Reporter: Rajith Attapattu >Priority: Minor > Fix For: 0.15 > > > As per the JMS spec, vendor specific message properties should be prefixed > with "JMS_" > Since we are including "qpid.subject" in all outgoing messages, it's causing > a TCK failure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3838) [JMS] Vendor specific properties should be prefixed with JMS_
[JMS] Vendor specific properties should be prefixed with JMS_ - Key: QPID-3838 URL: https://issues.apache.org/jira/browse/QPID-3838 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.12, 0.14 Reporter: Rajith Attapattu Priority: Minor Fix For: 0.15 As per the JMS spec, vendor specific message properties should be prefixed with "JMS_" Since we are including "qpid.subject" in all outgoing messages, it's causing a TCK failure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3380) Allow to get/set encoding type for JMS messages
[ https://issues.apache.org/jira/browse/QPID-3380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajith Attapattu updated QPID-3380: --- Fix Version/s: (was: 0.14) 0.15 > Allow to get/set encoding type for JMS messages > --- > > Key: QPID-3380 > URL: https://issues.apache.org/jira/browse/QPID-3380 > Project: Qpid > Issue Type: Improvement > Components: Java Client >Reporter: Rajith Attapattu >Assignee: Rajith Attapattu >Priority: Minor > Fix For: 0.15 > > > The JMS API does not provide a way to get/set the content type. > Therefore it would be nice to allow a way to get/set the AMQP content type > via the message properties. > The JMS API (and the Qpid API) relies on the content-type for identifying > map, text and eventually list messages. > Therefore the user needs to be careful when using the above feature and we > need to put a stern warning in our documentation about this. > However when using bytes and text messages, this improvement allows a nice > way for an application to provide specialized content-types like "text/xml" > ..etc. > We could use "x-amqp.content-type" as the message property (key) to retrieve > the content-type from the underlying message properties. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-2643) Support Visual Studio 2010
[ https://issues.apache.org/jira/browse/QPID-2643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajith Attapattu updated QPID-2643: --- Fix Version/s: (was: 0.14) 0.15 > Support Visual Studio 2010 > -- > > Key: QPID-2643 > URL: https://issues.apache.org/jira/browse/QPID-2643 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Affects Versions: 0.7 > Environment: visual studio 2010 c++ express >Reporter: Jinius >Assignee: Chuck Rolke > Labels: vs10, win64 > Fix For: 0.15 > > Attachments: Patch-2010-02.patch, QPID-2643-VS2010-01.patch > > > nmake compile failed at > C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\iterator(142) > : error C2039: 'value_type' : is not a memb > er of 'qpid::framing::List' > C:\A.svn_qpid\cpp\include\qpid/framing/List.h(40) : see declaration > of 'qpid::framing::List' > C:\A.svn_qpid\cpp\src\qpid\amqp_0_10\Codecs.cpp(51) : see reference > to class template instantiation 'std::insert > _iterator<_Container>' being compiled > with > [ > _Container=qpid::framing::List > ] > C:\svn_qpid\cpp\src\qpid\amqp_0_10\Codecs.cpp(83) : see reference to > function template instantiation 'void qpi > d::amqp_0_10::convert(__cdecl > *)(const qpid::types:: > Variant &)>(const std::list<_Ty> &,U &,F)' being compiled > with > [ > T=qpid::framing::FieldValue, > _Ty=qpid::types::Variant, > U=qpid::framing::List, > F=boost::shared_ptr (__cdecl *)(const > qpid::types::Variant &) > ] > C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\iterator(149) > : error C2182: '_Val' : illegal use of type > 'void' > C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\iterator(156) > : error C2182: '_Val' : illegal use of type > 'void' > NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~1.0\VC\bin\cl.exe' : return > code '0x2' > Stop. > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio > 10.0\VC\BIN\nmake.exe"' : return code '0x2' > Stop. > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio > 10.0\VC\BIN\nmake.exe"' : return code '0x2' -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3398) LegacyLVQ should not impose extra semantics on remove function
[ https://issues.apache.org/jira/browse/QPID-3398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajith Attapattu updated QPID-3398: --- Fix Version/s: (was: 0.14) 0.15 > LegacyLVQ should not impose extra semantics on remove function > -- > > Key: QPID-3398 > URL: https://issues.apache.org/jira/browse/QPID-3398 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Reporter: michael j. goulish >Assignee: michael j. goulish > Fix For: 0.15 > > > LegacyLVQ imposes extra semantics on the remove function beyond what its > parent MessageMap specifies. > It requires the caller to pass in a message with the same payload -- which > seems weird. > It should instead pass back the message that was deleted, just like its > parent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3388) Implement producer capacity to leverage producer flow control implemented by the C++ broker
[ https://issues.apache.org/jira/browse/QPID-3388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajith Attapattu updated QPID-3388: --- Fix Version/s: (was: 0.14) 0.15 > Implement producer capacity to leverage producer flow control implemented by > the C++ broker > > > Key: QPID-3388 > URL: https://issues.apache.org/jira/browse/QPID-3388 > Project: Qpid > Issue Type: New Feature > Components: Java Client >Reporter: Rajith Attapattu >Assignee: Rajith Attapattu > Fix For: 0.15 > > > Currently the capacity specified via the address syntax is not utilized by > the JMS producer. > If the JMS client implements this feature then it could leverage the producer > side flow control feature implemented by the C++ broker QPID-2935. > Once implemented the JMS sender will only send messages up to it's capacity > and will await until the broker sends completions to replenish credit. > We also need to consider backwards compatibility, therefore producer side > flow control should be explicitly triggered via setting the capacity. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3350) Python federation tests (federation.FederationTests.*) leak connections
[ https://issues.apache.org/jira/browse/QPID-3350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajith Attapattu updated QPID-3350: --- Fix Version/s: (was: 0.14) 0.15 > Python federation tests (federation.FederationTests.*) leak connections > --- > > Key: QPID-3350 > URL: https://issues.apache.org/jira/browse/QPID-3350 > Project: Qpid > Issue Type: Bug >Affects Versions: 0.12 >Reporter: Kim van der Riet >Assignee: Ken Giusti >Priority: Minor > Fix For: 0.15 > > > Several (but not all) the federation tests leak connection objects. This > causes the connections and hence the threads behind them to remain active > beyond the life of the test, and are cleaned up only when the entire test set > completes. This test set is short enough that there is currently no > side-effect, but if the test set is lengthened, then tests could potentially > fail because there are no more handles available for threads. (In Linux, the > default is 1024 handles per user.) > By observing calls to qpid.Connection.start() and qpid.Connection.close(), > tests can be seen where start() is called for a connection, but no matching > close() exists. Using this technique, the following tests were observed to > leak connections (with the number of leaked connections): > federation.FederationTests.test_dynamic_direct (1) > federation.FederationTests.test_dynamic_direct_reorigin (1) > federation.FederationTests.test_dynamic_fanout (1) > federation.FederationTests.test_dynamic_headers_all (1) > federation.FederationTests.test_dynamic_headers_any (1) > federation.FederationTests.test_dynamic_headers_reorigin (1) > federation.FederationTests.test_dynamic_headers_reorigin_xml (1) > federation.FederationTests.test_dynamic_headers_unbind (1) > federation.FederationTests.test_dynamic_headers_unbind_xml (1) > federation.FederationTests.test_dynamic_headers_xml (1) > federation.FederationTests.test_dynamic_topic (1) > federation.FederationTests.test_dynamic_topic_nodup (1) > federation.FederationTests.test_dynamic_topic_reorigin (1) > federation.FederationTests.test_pull_from_exchange (1) > federation.FederationTests.test_pull_from_queue (1) > federation.FederationTests.test_push_to_exchange (1) > federation.FederationTests.test_tracing (1) > federation.FederationTests.test_tracing_automatic (1) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3462) Failover is not transparent when using CLIENT_ACK mode
[ https://issues.apache.org/jira/browse/QPID-3462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajith Attapattu updated QPID-3462: --- Fix Version/s: (was: 0.14) 0.15 > Failover is not transparent when using CLIENT_ACK mode > -- > > Key: QPID-3462 > URL: https://issues.apache.org/jira/browse/QPID-3462 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.10, 0.12 >Reporter: Rajith Attapattu >Assignee: Rajith Attapattu > Fix For: 0.15 > > > If a session is using CLIENT_ACK mode fails over to another broker, and calls > acknowledge on a message it received before failover, the client throws an > IllegalStateException. > The JMS spec states, that the IllegalStateException should only be thrown if > the session is closed. When failover happens the JMS session (or the JMS > Connection) is not closed, instead we transparently reconnect and create a > new AMQP session and allow the application to continue as nothing happens. > Therefore throwing the above exception is incorrect. > We have three options for handling this case. > 1. Throw a JMSException notifying the application that this message was > received in the previous session. This notifies the application that the > acknowledge didn't succeed and the message is going to be redelivered. > 2. Not throw an exception at all. The application is anyhow prepared to > handle duplicates, so this would not be an issue at all. With JMS the last > acked message is always in doubt. If the application is using CLIENT_ACK and > acknowledging after 'n' messages, then it should be prepared to handle 'n' > duplicates in the event of a failover. > 2. The client library can make it totally transparent by not throwing an > exception at all. > Instead it can look up this messages (along with all the other unacked > messages upto that point) in it's dispatch queue received after failover. The > messages can be identified using the message ID (and they will also be marked > re-delivered by the broker). > It can then call acknowledge on these messages and remove them from the > dispatch queue. i.e they will not be redelivered to the application at all. > What do you think is the best option? > Regards, > Rajith -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3461) A SessionException is thrown (instead of a JMSException) when an error occurs during a commit.
[ https://issues.apache.org/jira/browse/QPID-3461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajith Attapattu updated QPID-3461: --- Fix Version/s: (was: 0.14) 0.15 > A SessionException is thrown (instead of a JMSException) when an error occurs > during a commit. > -- > > Key: QPID-3461 > URL: https://issues.apache.org/jira/browse/QPID-3461 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.10, 0.12 >Reporter: Rajith Attapattu >Assignee: Rajith Attapattu > Fix For: 0.15 > > Attachments: TxFailover.java > > > If the broker throws a session level exception, during or just before the > client invokes a commit on a transaction, the JMS client throws a > SessionException instead of a JMSException. > This is due to the AMQSession_0_10.java not handing the SessionException. > (Please note this issue is only present in the 0-10 code path). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3401) Refactor address resolution code
[ https://issues.apache.org/jira/browse/QPID-3401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajith Attapattu updated QPID-3401: --- Fix Version/s: (was: 0.14) 0.15 > Refactor address resolution code > > > Key: QPID-3401 > URL: https://issues.apache.org/jira/browse/QPID-3401 > Project: Qpid > Issue Type: Improvement > Components: Java Client >Reporter: Rajith Attapattu >Assignee: Rajith Attapattu > Fix For: 0.15 > > Attachments: QPID-3401-systests.patch, QPID-3401.patch, > class_diagram.png, model2.gif > > > After some thought it seems that the following JIRA's would benefit from some > reworking of the address resolution code as the original design had a few > flaws based on incorrect understanding of the address syntax. > QPID-3265 > QPID-3317 > QPID-3271 > The redesign would be minimal and not very disruptive. The goal is to fix > certain design flaws in the current code, rather than a complete redesign. I > am planning to reuse as much code as possible to ensure we don't throw away > tested code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3466) The toString() method for JMSDestination and JMSReplyTo is not formatted properly according to the destination syntax.
[ https://issues.apache.org/jira/browse/QPID-3466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajith Attapattu updated QPID-3466: --- Fix Version/s: (was: 0.14) 0.15 > The toString() method for JMSDestination and JMSReplyTo is not formatted > properly according to the destination syntax. > -- > > Key: QPID-3466 > URL: https://issues.apache.org/jira/browse/QPID-3466 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.10, 0.12 >Reporter: Rajith Attapattu >Assignee: Rajith Attapattu >Priority: Minor > Fix For: 0.15 > > > The value of toString() on the JMS Destination of a message being sent is > different from to the toString() value of JMS Destination of the same message > on the receiver side. This sometimes confuses users when trying to debug > applications. > Ex for client using the ADDR syntax. > Sender side > JMS Destination: 'amq.direct'/'test'; None > Receiver side > JMS Destination: direct://amq.direct/test/test?routingkey='test' > It would be nice if the string representation of JMSDestination and the > JMSReplyTo destination is formatted according to the chosen destination > syntax. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3583) 0.14 release tasks
[ https://issues.apache.org/jira/browse/QPID-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajith Attapattu updated QPID-3583: --- Fix Version/s: (was: 0.14) 0.15 > 0.14 release tasks > -- > > Key: QPID-3583 > URL: https://issues.apache.org/jira/browse/QPID-3583 > Project: Qpid > Issue Type: Task > Components: Packaging >Affects Versions: 0.14 >Reporter: Justin Ross >Assignee: Justin Ross > Fix For: 0.15 > > > A bug to track various release tasks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: handling no-local for existing queues
One could argue that the "no-local" should be treated the same way as selectors on a durable subscription - that is that the "no-local"ness is somehow encoded into the binding (if queue has exclusive consumer and consumer connection == producer consumer then don't enqueue) Certainly seems wrong to be retaining those messages -- Rob On 13 February 2012 23:03, Robbie Gemmell wrote: > On 13 February 2012 21:59, Rob Godfrey wrote: >> <*snip*> >> > The client currently only sends the no-local argument during queue > creation as you mentioned, but there is support in the protocol for > adding arguments to subscriptions so it could potentially be added > there too (The protocol actually has a no-local field on the file and > stream consume methods, so why it doesn't on the standard subscribe > method I'm not sure). I vaguely remembered something like this hence the question. Again speaking with Gordon I found the C++ broker does not support no-local being sent as an argument during subscription. However given the requirements around no-local for JMS I believe we can just get away with Topics and not worry about Queues. >> >> The "interesting" problem is durable subscriptions I would have >> thought - which are essentially queues. A client can disconnect, and >> a new connection subscribe, both with no-local set, but obviously >> "no-local" now has a different meaning (since the connection in >> question is different). >> >> -- Rob >> > > DurSubs and no-local are interesting. E.g. > https://issues.apache.org/jira/browse/QPID-3605 :) > > Robbie > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: handling no-local for existing queues
On 13 February 2012 21:59, Rob Godfrey wrote: > <*snip*> > The client currently only sends the no-local argument during queue creation as you mentioned, but there is support in the protocol for adding arguments to subscriptions so it could potentially be added there too (The protocol actually has a no-local field on the file and stream consume methods, so why it doesn't on the standard subscribe method I'm not sure). >>> >>> I vaguely remembered something like this hence the question. >>> Again speaking with Gordon I found the C++ broker does not support >>> no-local being sent as an argument during subscription. >>> However given the requirements around no-local for JMS I believe we >>> can just get away with Topics and not worry about Queues. > > The "interesting" problem is durable subscriptions I would have > thought - which are essentially queues. A client can disconnect, and > a new connection subscribe, both with no-local set, but obviously > "no-local" now has a different meaning (since the connection in > question is different). > > -- Rob > DurSubs and no-local are interesting. E.g. https://issues.apache.org/jira/browse/QPID-3605 :) Robbie - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: handling no-local for existing queues
<*snip*> >>> The client currently only sends the no-local argument during queue >>> creation as you mentioned, but there is support in the protocol for >>> adding arguments to subscriptions so it could potentially be added >>> there too (The protocol actually has a no-local field on the file and >>> stream consume methods, so why it doesn't on the standard subscribe >>> method I'm not sure). >> >> I vaguely remembered something like this hence the question. >> Again speaking with Gordon I found the C++ broker does not support >> no-local being sent as an argument during subscription. >> However given the requirements around no-local for JMS I believe we >> can just get away with Topics and not worry about Queues. The "interesting" problem is durable subscriptions I would have thought - which are essentially queues. A client can disconnect, and a new connection subscribe, both with no-local set, but obviously "no-local" now has a different meaning (since the connection in question is different). -- Rob - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3837) [Java broker] improve exception message when attempt is made to redeclare an exchange with a different type on a 0-10 connection
[Java broker] improve exception message when attempt is made to redeclare an exchange with a different type on a 0-10 connection Key: QPID-3837 URL: https://issues.apache.org/jira/browse/QPID-3837 Project: Qpid Issue Type: Improvement Components: Java Broker Affects Versions: 0.14 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Priority: Minor Fix For: 0.15 Improve exception message when attempt is made to redeclare an exchange with a different type on a 0-10 connection. Curently when attempting to do so the exception is fairly vauge, saying "Cannot redeclare with a different exchange type", whereas the equivalent message for 0-9-1 connections is something more helpful like: "Attempt to redeclare exchange: amq.topic of type topic to fanout". The 0-10 message should be brought in line with the 0-9-1 message for clarity and consistency. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: handling no-local for existing queues
On 13 February 2012 19:42, Rajith Attapattu wrote: > On Mon, Feb 13, 2012 at 12:53 PM, Robbie Gemmell > wrote: >> I cross-posted this on the JIRA so I'll report it here incase anyone >> wants a discussion :) >> >> >> I think the JIRA title is perhaps a little misleading, given the >> number of tests running that show it does work to an extent. > > Actually it should have been (corrected now) does not work when using > address strings. > The fix for QPID-3539 was only added to the BURL part. > QPID-3539 was really just a Java broker change from what I remember, where the 0-10 path was incorrectly handling no-local at the session rather than connection level. I dont think the clients behaviour was modified at all, so it must have worked already for the BURL paths. >> Perhaps 'doesn't work when used on queues not originally declared no-local' >> would be clearer. The BURL usage may always send the queue declare, >> but redeclaring a queue that exists wont make it no-local. > > My bad, the intention of the JIRA was to address the issue of no-local > not working when using address strings. > But it seems I have unintentionally highlighted the issue of no-local > not working for existing queues. > > Speaking with Gordon, it seems, at-least from a JMS POV, that no local > for existing Queues is not an issue. > From the API doc "NoLocal - - if true, and the destination is a topic, > inhibits the delivery of messages published by its own connection. The > behavior for NoLocal is not specified if the destination is a queue. " > Since we obviously create the subscription queues for each topic at > the time of subscription, at least from a JMS pov we can easily ensure > that we pass the no-local argument when creating the queue. > Yeah, I must admit I did glance at the API earlier and saw the 'Destination' signature and assumed that meant Quues were fair game, but I didnt read the Javadoc or spec. If they arent given defined behaviour, then its fine the way it is based on the wording (for the BURL path that is, which does exactly what you propose based on the broker side code I saw earlier). >> The client currently only sends the no-local argument during queue >> creation as you mentioned, but there is support in the protocol for >> adding arguments to subscriptions so it could potentially be added >> there too (The protocol actually has a no-local field on the file and >> stream consume methods, so why it doesn't on the standard subscribe >> method I'm not sure). > > I vaguely remembered something like this hence the question. > Again speaking with Gordon I found the C++ broker does not support > no-local being sent as an argument during subscription. > However given the requirements around no-local for JMS I believe we > can just get away with Topics and not worry about Queues. > > Rajith Agreed (the Java broker doesnt support that just now either, I looked before replying earlier) > >> Robbie >> >> On 13 February 2012 17:36, Rajith Attapattu wrote: >>> IIRC the no-local argument is passed on during queue-declare. >>> But if you create a subscription with no-local=true on an existing >>> queue how should we handle this situation ? >>> >>> Perhaps there is also a way to pass no-local in the arguments map when >>> creating a subscription ? >>> >>> Regards, >>> >>> Rajith >>> >>> - >>> Apache Qpid - AMQP Messaging Implementation >>> Project: http://qpid.apache.org >>> Use/Interact: mailto:dev-subscr...@qpid.apache.org >>> >> >> - >> Apache Qpid - AMQP Messaging Implementation >> Project: http://qpid.apache.org >> Use/Interact: mailto:dev-subscr...@qpid.apache.org >> > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Resolved] (QPID-3638) incompatibility with new boost version 1.48
[ https://issues.apache.org/jira/browse/QPID-3638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved QPID-3638. Resolution: Fixed Fix Version/s: 0.15 > incompatibility with new boost version 1.48 > --- > > Key: QPID-3638 > URL: https://issues.apache.org/jira/browse/QPID-3638 > Project: Qpid > Issue Type: Bug > Components: C++ Broker, C++ Client >Affects Versions: 0.14 > Environment: Fedora rawhide >Reporter: Nuno Santos >Assignee: Ted Ross >Priority: Minor > Labels: boost > Fix For: 0.15 > > > qpid/log/Logger.cpp:26:43: fatal error: boost/pool/detail/singleton.hpp: No > such file or directory > Looks like the code under boost/pool has been re-organized in version 1.48, > and that file no longer exists. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Assigned] (QPID-3638) incompatibility with new boost version 1.48
[ https://issues.apache.org/jira/browse/QPID-3638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reassigned QPID-3638: -- Assignee: Ted Ross > incompatibility with new boost version 1.48 > --- > > Key: QPID-3638 > URL: https://issues.apache.org/jira/browse/QPID-3638 > Project: Qpid > Issue Type: Bug > Components: C++ Broker, C++ Client >Affects Versions: 0.14 > Environment: Fedora rawhide >Reporter: Nuno Santos >Assignee: Ted Ross >Priority: Minor > Labels: boost > > qpid/log/Logger.cpp:26:43: fatal error: boost/pool/detail/singleton.hpp: No > such file or directory > Looks like the code under boost/pool has been re-organized in version 1.48, > and that file no longer exists. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: handling no-local for existing queues
On Mon, Feb 13, 2012 at 12:53 PM, Robbie Gemmell wrote: > I cross-posted this on the JIRA so I'll report it here incase anyone > wants a discussion :) > > > I think the JIRA title is perhaps a little misleading, given the > number of tests running that show it does work to an extent. Actually it should have been (corrected now) does not work when using address strings. The fix for QPID-3539 was only added to the BURL part. > Perhaps 'doesn't work when used on queues not originally declared no-local' > would be clearer. The BURL usage may always send the queue declare, > but redeclaring a queue that exists wont make it no-local. My bad, the intention of the JIRA was to address the issue of no-local not working when using address strings. But it seems I have unintentionally highlighted the issue of no-local not working for existing queues. Speaking with Gordon, it seems, at-least from a JMS POV, that no local for existing Queues is not an issue. >From the API doc "NoLocal - - if true, and the destination is a topic, inhibits the delivery of messages published by its own connection. The behavior for NoLocal is not specified if the destination is a queue. " Since we obviously create the subscription queues for each topic at the time of subscription, at least from a JMS pov we can easily ensure that we pass the no-local argument when creating the queue. > The client currently only sends the no-local argument during queue > creation as you mentioned, but there is support in the protocol for > adding arguments to subscriptions so it could potentially be added > there too (The protocol actually has a no-local field on the file and > stream consume methods, so why it doesn't on the standard subscribe > method I'm not sure). I vaguely remembered something like this hence the question. Again speaking with Gordon I found the C++ broker does not support no-local being sent as an argument during subscription. However given the requirements around no-local for JMS I believe we can just get away with Topics and not worry about Queues. Rajith > Robbie > > On 13 February 2012 17:36, Rajith Attapattu wrote: >> IIRC the no-local argument is passed on during queue-declare. >> But if you create a subscription with no-local=true on an existing >> queue how should we handle this situation ? >> >> Perhaps there is also a way to pass no-local in the arguments map when >> creating a subscription ? >> >> Regards, >> >> Rajith >> >> - >> Apache Qpid - AMQP Messaging Implementation >> Project: http://qpid.apache.org >> Use/Interact: mailto:dev-subscr...@qpid.apache.org >> > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3547) qpid-config currently doesn't display useful information about headers exchange bindings
[ https://issues.apache.org/jira/browse/QPID-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13207103#comment-13207103 ] jirapos...@reviews.apache.org commented on QPID-3547: - --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/3839/#review5055 --- Ship it! This looks good. The only thing I might have done differently is to use "%r" instead of "%s" for the arguments. However, since the arguments are always of type "dict", both formats are treated the same so it's fine the way it is. - Ted On 2012-02-10 21:02:10, Gordon Sim wrote: bq. bq. --- bq. This is an automatically generated e-mail. To reply, visit: bq. https://reviews.apache.org/r/3839/ bq. --- bq. bq. (Updated 2012-02-10 21:02:10) bq. bq. bq. Review request for Kenneth Giusti, Ted Ross and Nuno Santos. bq. bq. bq. Summary bq. --- bq. bq. So that for e.g. headers exchanges you can actually see what the bindings are. bq. bq. bq. This addresses bug QPID-3547. bq. https://issues.apache.org/jira/browse/QPID-3547 bq. bq. bq. Diffs bq. - bq. bq./trunk/qpid/tools/src/py/qpid-config 1079726 bq. bq. Diff: https://reviews.apache.org/r/3839/diff bq. bq. bq. Testing bq. --- bq. bq. Basic bq. bq. bq. Thanks, bq. bq. Gordon bq. bq. > qpid-config currently doesn't display useful information about headers > exchange bindings > > > Key: QPID-3547 > URL: https://issues.apache.org/jira/browse/QPID-3547 > Project: Qpid > Issue Type: New Feature > Components: Tools >Affects Versions: 0.10 > Environment: qpid-config python tool >Reporter: Fraser Adams >Priority: Trivial > Labels: features > > qpid-config doesn't display useful binding information for headers exchange > bindings, for the headers exchange the binding key is really just a handle. > The most basic fix would be to test for the presence of bind.arguments in the > QueueListRecurse and ExchangeListRecurse methods and if present to display > the bind.arguments. > For example in QueueListRecurse: > if bind.arguments: > print "bind [%s] => %s %s" % > (bind.bindingKey, ename, bind.arguments) > else: > print "bind [%s] => %s" % (bind.bindingKey, > ename) > and in ExchangeListRecurse: > if bind.arguments: > print "bind [%s] => %s %s" % > (bind.bindingKey, qname, bind.arguments) > else: > print "bind [%s] => %s" % (bind.bindingKey, > qname) > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3836) no-local does not work for Qpid 0-10 JMS client when using address strings
[ https://issues.apache.org/jira/browse/QPID-3836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajith Attapattu updated QPID-3836: --- Summary: no-local does not work for Qpid 0-10 JMS client when using address strings (was: no-local does not work for Qpid 0-10 JMS client) > no-local does not work for Qpid 0-10 JMS client when using address strings > -- > > Key: QPID-3836 > URL: https://issues.apache.org/jira/browse/QPID-3836 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.12 >Reporter: Rajith Attapattu >Assignee: Rajith Attapattu > Fix For: 0.15 > > > If no-local is set to true when create a consumer or a durable subscriber, > messages published by the same connection should not be seen by this consumer. > Currently due to a bug no-local is not passed correctly when creating the > subscription queue. > All though this works for Topics and Queues created when this information is > available, not sure how this should be handled when subscribing to an already > existing queue. > AKAIK the no-local argument is passed on during queue-declare. Perhaps there > is also a way to pass this on when creating a subscription ? > (I will update the description when I find the answer to the above question). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3835) [Java broker] DurableSubscriptions without a selector on 0-10 connections will initially be unsubscribed at reconnect following upgrade of a legacy message store
[ https://issues.apache.org/jira/browse/QPID-3835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-3835: - Status: Ready To Review (was: In Progress) > [Java broker] DurableSubscriptions without a selector on 0-10 connections > will initially be unsubscribed at reconnect following upgrade of a legacy > message store > - > > Key: QPID-3835 > URL: https://issues.apache.org/jira/browse/QPID-3835 > Project: Qpid > Issue Type: Bug > Components: Java Broker, Java Broker BDB Store >Affects Versions: 0.14 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Critical > Fix For: 0.15 > > > DurableSubscriptions without a selector on 0-10 connections will initially be > unsubscribed at reconnect following upgrade of a legacy message store. If an > older broker release is upgraded to the current format, the bindings for a > DurableSubscriptions backing queue must be modified if it previously had no > selector, to ensure the client can correctly reconnect to the > DurableSubscription without having the existing messages lost due to an > unsubscribe() bring performed. > This is because the newer clients send the server-side selector argument with > an empty value to signfify the lack of a selector (to allow later querying if > the selector has changed in any way when using the 0-10 client) whereas old > clients used the complete lack of the argument to signal this. As a result, > when determining if the selector has changed following a store upgrade from a > legacy broker, the client would incorrectly believe it had and follow the JMS > spec behaviour of doing an unsubscribe() before continuing, which would have > the effect of deleting the backing queue. The bindings of such queues should > be manipulated during the upgrade process to add the selector argument if it > isnt already present. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: handling no-local for existing queues
I cross-posted this on the JIRA so I'll report it here incase anyone wants a discussion :) I think the JIRA title is perhaps a little misleading, given the number of tests running that show it does work to an extent. Perhaps 'doesn't work when used on queues not originally declared no-local' would be clearer. The BURL usage may always send the queue declare, but redeclaring a queue that exists wont make it no-local. The client currently only sends the no-local argument during queue creation as you mentioned, but there is support in the protocol for adding arguments to subscriptions so it could potentially be added there too (The protocol actually has a no-local field on the file and stream consume methods, so why it doesn't on the standard subscribe method I'm not sure). Robbie On 13 February 2012 17:36, Rajith Attapattu wrote: > IIRC the no-local argument is passed on during queue-declare. > But if you create a subscription with no-local=true on an existing > queue how should we handle this situation ? > > Perhaps there is also a way to pass no-local in the arguments map when > creating a subscription ? > > Regards, > > Rajith > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3836) no-local does not work for Qpid 0-10 JMS client
[ https://issues.apache.org/jira/browse/QPID-3836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13207008#comment-13207008 ] Robbie Gemmell commented on QPID-3836: -- I think the title is perhaps a little misleading, given the number of tests running that show it does work to an extent. Perhaps 'doesn't work when used on queues not originally declared no-local' would be clearer. The BURL usage may always send the queue declare, but redeclaring a queue that exists wont make it no-local. The client currently only sends the no-local argument during queue creation as you mentioned, but there is support in the protocol for adding arguments to subscriptions so it could potentially be added there too (The protocol actually has a no-local field on the file and stream consume methods, so why it doesn't on the standard subscribe method I'm not sure) > no-local does not work for Qpid 0-10 JMS client > --- > > Key: QPID-3836 > URL: https://issues.apache.org/jira/browse/QPID-3836 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.12 >Reporter: Rajith Attapattu >Assignee: Rajith Attapattu > Fix For: 0.15 > > > If no-local is set to true when create a consumer or a durable subscriber, > messages published by the same connection should not be seen by this consumer. > Currently due to a bug no-local is not passed correctly when creating the > subscription queue. > All though this works for Topics and Queues created when this information is > available, not sure how this should be handled when subscribing to an already > existing queue. > AKAIK the no-local argument is passed on during queue-declare. Perhaps there > is also a way to pass this on when creating a subscription ? > (I will update the description when I find the answer to the above question). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
handling no-local for existing queues
IIRC the no-local argument is passed on during queue-declare. But if you create a subscription with no-local=true on an existing queue how should we handle this situation ? Perhaps there is also a way to pass no-local in the arguments map when creating a subscription ? Regards, Rajith - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3836) no-local does not work for Qpid 0-10 JMS client
[ https://issues.apache.org/jira/browse/QPID-3836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206998#comment-13206998 ] Rajith Attapattu commented on QPID-3836: The fix provided in QPID-3539 only works for the BURL format. This format always declares a queue, so the above issue does not arise. > no-local does not work for Qpid 0-10 JMS client > --- > > Key: QPID-3836 > URL: https://issues.apache.org/jira/browse/QPID-3836 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.12 >Reporter: Rajith Attapattu >Assignee: Rajith Attapattu > Fix For: 0.15 > > > If no-local is set to true when create a consumer or a durable subscriber, > messages published by the same connection should not be seen by this consumer. > Currently due to a bug no-local is not passed correctly when creating the > subscription queue. > All though this works for Topics and Queues created when this information is > available, not sure how this should be handled when subscribing to an already > existing queue. > AKAIK the no-local argument is passed on during queue-declare. Perhaps there > is also a way to pass this on when creating a subscription ? > (I will update the description when I find the answer to the above question). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3836) no-local does not work for Qpid 0-10 JMS client
no-local does not work for Qpid 0-10 JMS client --- Key: QPID-3836 URL: https://issues.apache.org/jira/browse/QPID-3836 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.12 Reporter: Rajith Attapattu Assignee: Rajith Attapattu Fix For: 0.15 If no-local is set to true when create a consumer or a durable subscriber, messages published by the same connection should not be seen by this consumer. Currently due to a bug no-local is not passed correctly when creating the subscription queue. All though this works for Topics and Queues created when this information is available, not sure how this should be handled when subscribing to an already existing queue. AKAIK the no-local argument is passed on during queue-declare. Perhaps there is also a way to pass this on when creating a subscription ? (I will update the description when I find the answer to the above question). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3835) [Java broker] DurableSubscriptions without a selector on 0-10 connections will initially be unsubscribed at reconnect following upgrade of a legacy message store
[Java broker] DurableSubscriptions without a selector on 0-10 connections will initially be unsubscribed at reconnect following upgrade of a legacy message store - Key: QPID-3835 URL: https://issues.apache.org/jira/browse/QPID-3835 Project: Qpid Issue Type: Bug Components: Java Broker, Java Broker BDB Store Affects Versions: 0.14 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Priority: Critical Fix For: 0.15 DurableSubscriptions without a selector on 0-10 connections will initially be unsubscribed at reconnect following upgrade of a legacy message store. If an older broker release is upgraded to the current format, the bindings for a DurableSubscriptions backing queue must be modified if it previously had no selector, to ensure the client can correctly reconnect to the DurableSubscription without having the existing messages lost due to an unsubscribe() bring performed. This is because the newer clients send the server-side selector argument with an empty value to signfify the lack of a selector (to allow later querying if the selector has changed in any way when using the 0-10 client) whereas old clients used the complete lack of the argument to signal this. As a result, when determining if the selector has changed following a store upgrade from a legacy broker, the client would incorrectly believe it had and follow the JMS spec behaviour of doing an unsubscribe() before continuing, which would have the effect of deleting the backing queue. The bindings of such queues should be manipulated during the upgrade process to add the selector argument if it isnt already present. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3834) Firewall plugin does not reset its configuration when it is removed completely from broker config file and broker configuration is reloaded via JMX "ConfigurationManagemen
Firewall plugin does not reset its configuration when it is removed completely from broker config file and broker configuration is reloaded via JMX "ConfigurationManagement reload" Key: QPID-3834 URL: https://issues.apache.org/jira/browse/QPID-3834 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.15 Reporter: Alex Rudyy Priority: Minor On reloading broker configuration via JMX "ConfigurationManagement reload" after removing firewall settings the firewall plugin does not reset its configuration. The previous settings remain active and invoked on each connection establishing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Assigned] (QPID-3833) Only string values for LVQ key are accepted
[ https://issues.apache.org/jira/browse/QPID-3833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reassigned QPID-3833: Assignee: Gordon Sim > Only string values for LVQ key are accepted > --- > > Key: QPID-3833 > URL: https://issues.apache.org/jira/browse/QPID-3833 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Affects Versions: 0.15 >Reporter: Gordon Sim >Assignee: Gordon Sim > > Would be nice to allow other types as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3832) Qpid 0.14 broke transport connection setting
[
https://issues.apache.org/jira/browse/QPID-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206884#comment-13206884
]
Gordon Sim commented on QPID-3832:
--
Sorry, that was my fault. Great analysis though! I'll try and get this fixed
for the next release.
> Qpid 0.14 broke transport connection setting
>
>
> Key: QPID-3832
> URL: https://issues.apache.org/jira/browse/QPID-3832
> Project: Qpid
> Issue Type: Bug
> Components: C++ Client
>Affects Versions: 0.14
>Reporter: Paul Colby
> Labels: SSL
>
> The transport connection setting was broken in r1156262.
> Consider the following test code:
> {code}
> #include
> int main(int argc, char *argv[]) {
> qpid::types::Variant::Map options;
> options["transport" ] = "ssl";
> qpid::messaging::Connection connection("localhost:5671", options);
> connection.open();
> return 0;
> }
> {code}
> Using Qpid 0.12 client libraries, the above code would use SSL. But with
> Qpid 0.14, the code will *not* use SSL.
> The change in behaviour is a result of code changes to the
> {{ConnectionImpl::tryConnect}} function in
> {{cpp/src/qpid/client/amqp0_10/ConnectionImpl.cpp}} in r1156262
> Prior to that revision, the {{SimpleUrlParser}} was used, and {{settings}}
> passed to a {{Connection::open}} overload directly. This worked fine.
> Post that revision, the code looks like this:
> {code}
> Url url(*i);
> if (url.getUser().size()) settings.username = url.getUser();
> if (url.getPass().size()) settings.password = url.getPass();
> QPID_LOG(debug, *i << " " << settings.protocol);
> QPID_LOG(debug, url);
> connection.open(url, settings);
> {code}
> (I added the {{QPID_LOG}} calls).
> The {{QPID_LOG}} calls produce output like:
> {code}
> localhost:5671 ssl
> amqp:tcp:localhost:5671
> {code}
> The problem is that the {{Url}} constructor is defaulting the protocol to TCP
> (via {{UrlParser::protocolAddr}}). Then, when the {{Connection::open}}
> overload is called, the {{Url}} object's defaulted-but-now-explicit
> {{protocol}} value (TCP) is used in preference to the {{settings.protocol}}
> value (SSL).
> I think the correct solution here, thought it would be non-trivial, would be
> to pass {{settings}} (or at least {{settings.protocol}}) to the {{Url}}
> constructor as an optional default protocol. Then the {{Url}} class should
> use that default protocol instead of TCP when the address string does not
> include an explicit protocol.
> Another option would be to provide some sort of {{Url::protocolWasDefaulted}}
> flag so that the {{ConnectionImpl::tryConnect}} function could override from
> {{settings}} when appropriate - this would be less code change, but the above
> solution would be more elegant IMO.
> Note, the obvious workaround is to always use explicit protocols in URLs.
> That is, always use "ssl:hostname" instead of "hostname".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Assigned] (QPID-3832) Qpid 0.14 broke transport connection setting
[
https://issues.apache.org/jira/browse/QPID-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim reassigned QPID-3832:
Assignee: Gordon Sim
> Qpid 0.14 broke transport connection setting
>
>
> Key: QPID-3832
> URL: https://issues.apache.org/jira/browse/QPID-3832
> Project: Qpid
> Issue Type: Bug
> Components: C++ Client
>Affects Versions: 0.14
>Reporter: Paul Colby
>Assignee: Gordon Sim
> Labels: SSL
>
> The transport connection setting was broken in r1156262.
> Consider the following test code:
> {code}
> #include
> int main(int argc, char *argv[]) {
> qpid::types::Variant::Map options;
> options["transport" ] = "ssl";
> qpid::messaging::Connection connection("localhost:5671", options);
> connection.open();
> return 0;
> }
> {code}
> Using Qpid 0.12 client libraries, the above code would use SSL. But with
> Qpid 0.14, the code will *not* use SSL.
> The change in behaviour is a result of code changes to the
> {{ConnectionImpl::tryConnect}} function in
> {{cpp/src/qpid/client/amqp0_10/ConnectionImpl.cpp}} in r1156262
> Prior to that revision, the {{SimpleUrlParser}} was used, and {{settings}}
> passed to a {{Connection::open}} overload directly. This worked fine.
> Post that revision, the code looks like this:
> {code}
> Url url(*i);
> if (url.getUser().size()) settings.username = url.getUser();
> if (url.getPass().size()) settings.password = url.getPass();
> QPID_LOG(debug, *i << " " << settings.protocol);
> QPID_LOG(debug, url);
> connection.open(url, settings);
> {code}
> (I added the {{QPID_LOG}} calls).
> The {{QPID_LOG}} calls produce output like:
> {code}
> localhost:5671 ssl
> amqp:tcp:localhost:5671
> {code}
> The problem is that the {{Url}} constructor is defaulting the protocol to TCP
> (via {{UrlParser::protocolAddr}}). Then, when the {{Connection::open}}
> overload is called, the {{Url}} object's defaulted-but-now-explicit
> {{protocol}} value (TCP) is used in preference to the {{settings.protocol}}
> value (SSL).
> I think the correct solution here, thought it would be non-trivial, would be
> to pass {{settings}} (or at least {{settings.protocol}}) to the {{Url}}
> constructor as an optional default protocol. Then the {{Url}} class should
> use that default protocol instead of TCP when the address string does not
> include an explicit protocol.
> Another option would be to provide some sort of {{Url::protocolWasDefaulted}}
> flag so that the {{ConnectionImpl::tryConnect}} function could override from
> {{settings}} when appropriate - this would be less code change, but the above
> solution would be more elegant IMO.
> Note, the obvious workaround is to always use explicit protocols in URLs.
> That is, always use "ssl:hostname" instead of "hostname".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3833) Only string values for LVQ key are accepted
Only string values for LVQ key are accepted --- Key: QPID-3833 URL: https://issues.apache.org/jira/browse/QPID-3833 Project: Qpid Issue Type: Improvement Components: C++ Broker Affects Versions: 0.15 Reporter: Gordon Sim Would be nice to allow other types as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
