Re: Review Request: Continuation of Qpid C++ spring cleaning - QPID-4905
On June 18, 2013, 9:08 p.m., Andrew Stitcher wrote: I'm not especially attached the the terminology Publisher, it comes from the pre-existing setPublisher() method on the Message. However, the purpose of this object is certainly to do with Authentication and Ownership of the thing that is publishing the message, I think Publisher is a very poor name. At present that interface defines connection identity, with the identification of the publishing connection being the only concrete use. It could however just as well be used to identify the declaring connection for a queue. That said, I am going to be doing work to separate some of the protocol independent stuff from the 0-10 connection anyway and would rather this gets committed so I can move on. I may change the name o f that interface as part of that. - Gordon --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11944/#review22074 --- On June 18, 2013, 9:06 p.m., Andrew Stitcher wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11944/ --- (Updated June 18, 2013, 9:06 p.m.) Review request for qpid and Gordon Sim. Description --- This is a continuation of review 11628 - https://reviews.apache.org/r/11628/ Included in this review is the last change there merging broker::Connection and broker::ConnectionState and a further change that tidies up the interface of the Connection/Message classes to the Broker management code. This introduces a protocol independent Publisher interface that can be queried for the userID/Url/ObjectId and OwnershipToken of a message publisher. This is used primarily in authenticating management messages. This addresses bug QPID-4905. https://issues.apache.org/jira/browse/QPID-4905 Diffs - /trunk/qpid/cpp/src/CMakeLists.txt 1493903 /trunk/qpid/cpp/src/Makefile.am 1493903 /trunk/qpid/cpp/src/qpid/broker/Bridge.h 1493903 /trunk/qpid/cpp/src/qpid/broker/Bridge.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/Broker.h 1493903 /trunk/qpid/cpp/src/qpid/broker/Broker.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/Connection.h 1493903 /trunk/qpid/cpp/src/qpid/broker/Connection.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/ConnectionHandler.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/ConnectionState.h 1493903 /trunk/qpid/cpp/src/qpid/broker/ConnectionState.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/ConnectionToken.h 1493903 /trunk/qpid/cpp/src/qpid/broker/HandlerImpl.h 1493903 /trunk/qpid/cpp/src/qpid/broker/Message.h 1493903 /trunk/qpid/cpp/src/qpid/broker/Message.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/OwnershipToken.h 1493903 /trunk/qpid/cpp/src/qpid/broker/Publisher.h PRE-CREATION /trunk/qpid/cpp/src/qpid/broker/Queue.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/SaslAuthenticator.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/SemanticState.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/SessionAdapter.h 1493903 /trunk/qpid/cpp/src/qpid/broker/SessionAdapter.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/SessionContext.h 1493903 /trunk/qpid/cpp/src/qpid/broker/SessionHandler.h 1493903 /trunk/qpid/cpp/src/qpid/broker/SessionHandler.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/SessionState.h 1493903 /trunk/qpid/cpp/src/qpid/broker/SessionState.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/amqp/ManagedConnection.h 1493903 /trunk/qpid/cpp/src/qpid/broker/amqp/ManagedConnection.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/amqp/ManagedSession.h 1493903 /trunk/qpid/cpp/src/qpid/broker/amqp/ManagedSession.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/windows/SaslAuthenticator.cpp 1493903 /trunk/qpid/cpp/src/qpid/ha/ReplicatingSubscription.cpp 1493903 /trunk/qpid/cpp/src/qpid/management/ManagementAgent.h 1493903 /trunk/qpid/cpp/src/qpid/management/ManagementAgent.cpp 1493903 /trunk/qpid/cpp/src/qpid/sys/ConnectionOutputHandlerPtr.h 1493903 Diff: https://reviews.apache.org/r/11944/diff/ Testing --- cmake: make test Thanks, Andrew Stitcher
[jira] [Resolved] (QPID-4933) The qpid_messaging gem does not install on Ruby greater than 1.8.7
[ https://issues.apache.org/jira/browse/QPID-4933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce resolved QPID-4933. Resolution: Fixed Fix Version/s: 0.23 Added a check for the current Ruby version. Set the appropriate CFLAGS in extconf.rb based on that version. The qpid_messaging gem does not install on Ruby greater than 1.8.7 -- Key: QPID-4933 URL: https://issues.apache.org/jira/browse/QPID-4933 Project: Qpid Issue Type: Bug Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce Priority: Blocker Fix For: 0.23 When installing on Ruby 1.9.7 or 2.0.0 the gem fails to find the C++ libraries. The issue appears to be command line options passed as part of generating the Makefile with mkmfs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Website update 6
Hi Justin, I had a quick lookand noticed a few issues: The site can't be used at all in IE8 as it loads up in XML view. This seems like a blocker to me, as IE8 is apparently still one of the most used browsers. The JCA download link on http://people.apache.org/~jross/transom/head/download.html is pointing at the Java broker archive. Some of the Features links are broken on the Java broker component page: http://people.apache.org/~jross/transom/head/components/java-broker/index.html The download links on the newer individual release pages (e.g http://people.apache.org/~jross/transom/head/releases/qpid-0.22/index.htmland http://people.apache.org/~jross/transom/head/releases/qpid-proton-0.4/index.html) are linking directly to www.apache.org/dist instead of using the mirror system like the main download page does. Robbie On 17 June 2013 18:16, Justin Ross jr...@apache.org wrote: http://people.apache.org/~jross/transom/2013-06-17/ Previous versions: Update 5: http://people.apache.org/~jross/transom/2013-05-24/ http://qpid.2158936.n2.nabble.com/Website-update-5-td7593440.html Update 4: http://people.apache.org/~jross/transom/2013-05-10/ http://qpid.2158936.n2.nabble.com/Website-update-4-tt7592756.html Update 3: http://people.apache.org/~jross/transom/2013-04-16/ http://qpid.2158936.n2.nabble.com/Website-update-3-tt7591573.html Update 2: http://people.apache.org/~jross/transom/2013-04-03/ http://qpid.2158936.n2.nabble.com/Website-update-2-tt7591046.html Update 1: http://people.apache.org/~jross/transom/2013-03-26/ http://qpid.2158936.n2.nabble.com/Website-update-tt7590444.html Head version: http://people.apache.org/~jross/transom/head/ Changes: - Added selectors to cpp broker features - Added link to maven snapshot repo - Switched to using .htaccess for redirects - Simplified the steps to publish changes - Some scripting changes to adapt to using svnpubsub - Removed logo so it can be taken as a distinct question - Added highlighting of page-internal headings when linked - Added bug and enhancement queries for each component - Streamlined tab navigation on the search page This update doesn't represent as big a change as past updates. Instead, I'm closing things down in preparation for going live with the new site. I will start a vote thread on that question shortly. Nonetheless, I will continue publishing updates as I've done. Please keep your comments and ideas coming. Thanks! Justin - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4745) qpidd --port 0 sometimes fails with 'Can't bind to port 0.0.0.0:49337: Address already in use (qpid/sys/posix/Socket.cpp:206)'
[ https://issues.apache.org/jira/browse/QPID-4745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13687963#comment-13687963 ] ASF subversion and git services commented on QPID-4745: --- Commit 1494606 from [~aconway] [ https://svn.apache.org/r1494606 ] QPID-4745: Remove spurious --port option in qpidd-p0 qpidd --port 0 sometimes fails with 'Can't bind to port 0.0.0.0:49337: Address already in use (qpid/sys/posix/Socket.cpp:206)' --- Key: QPID-4745 URL: https://issues.apache.org/jira/browse/QPID-4745 Project: Qpid Issue Type: Improvement Components: C++ Clustering Affects Versions: 0.22 Reporter: Alan Conway Assignee: Alan Conway Priority: Minor Many of the tests use qpidd --port=0 to start a broker on an available port. Thhis sporadically fails with: Can't bind to port 0.0.0.0:49337: Address already in use (qpid/sys/posix/Socket.cpp:206) Many HA tests use --port=0 to start a broker on an available port, but then need to shutdown and restart the broker _on the same port_. This is not safe, on a busy system it is possible for another process to take the port between the time the broker is shut down and the time it is restarted. See also https://bugzilla.redhat.com/show_bug.cgi?id=906277 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4745) qpidd --port 0 sometimes fails with 'Can't bind to port 0.0.0.0:49337: Address already in use (qpid/sys/posix/Socket.cpp:206)'
[ https://issues.apache.org/jira/browse/QPID-4745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13687962#comment-13687962 ] Alan Conway commented on QPID-4745: --- I can't recall why I put that --port option in there so I'll take it out, as it does appear incorrect. Currently the broker for the python system tests is externally launched so qpidd-p0 can be a drop in replacement. We could move that into the python tests if there's benefit in doing so. ha_tests.py already such a launcher built in, but in that case it is doing more work than qpidd-p0, it holds onto ports so brokers can be restarted on the same port. qpidd --port 0 sometimes fails with 'Can't bind to port 0.0.0.0:49337: Address already in use (qpid/sys/posix/Socket.cpp:206)' --- Key: QPID-4745 URL: https://issues.apache.org/jira/browse/QPID-4745 Project: Qpid Issue Type: Improvement Components: C++ Clustering Affects Versions: 0.22 Reporter: Alan Conway Assignee: Alan Conway Priority: Minor Many of the tests use qpidd --port=0 to start a broker on an available port. Thhis sporadically fails with: Can't bind to port 0.0.0.0:49337: Address already in use (qpid/sys/posix/Socket.cpp:206) Many HA tests use --port=0 to start a broker on an available port, but then need to shutdown and restart the broker _on the same port_. This is not safe, on a busy system it is possible for another process to take the port between the time the broker is shut down and the time it is restarted. See also https://bugzilla.redhat.com/show_bug.cgi?id=906277 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Review Request: Continuation of Qpid C++ spring cleaning - QPID-4905
On June 18, 2013, 9:08 p.m., Andrew Stitcher wrote: I'm not especially attached the the terminology Publisher, it comes from the pre-existing setPublisher() method on the Message. However, the purpose of this object is certainly to do with Authentication and Ownership of the thing that is publishing the message, Gordon Sim wrote: I think Publisher is a very poor name. At present that interface defines connection identity, with the identification of the publishing connection being the only concrete use. It could however just as well be used to identify the declaring connection for a queue. That said, I am going to be doing work to separate some of the protocol independent stuff from the 0-10 connection anyway and would rather this gets committed so I can move on. I may change the name o f that interface as part of that. I could certainly change the interfce name to ConnectionIdentity if you prefer. - Andrew --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11944/#review22074 --- On June 18, 2013, 9:06 p.m., Andrew Stitcher wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11944/ --- (Updated June 18, 2013, 9:06 p.m.) Review request for qpid and Gordon Sim. Description --- This is a continuation of review 11628 - https://reviews.apache.org/r/11628/ Included in this review is the last change there merging broker::Connection and broker::ConnectionState and a further change that tidies up the interface of the Connection/Message classes to the Broker management code. This introduces a protocol independent Publisher interface that can be queried for the userID/Url/ObjectId and OwnershipToken of a message publisher. This is used primarily in authenticating management messages. This addresses bug QPID-4905. https://issues.apache.org/jira/browse/QPID-4905 Diffs - /trunk/qpid/cpp/src/CMakeLists.txt 1493903 /trunk/qpid/cpp/src/Makefile.am 1493903 /trunk/qpid/cpp/src/qpid/broker/Bridge.h 1493903 /trunk/qpid/cpp/src/qpid/broker/Bridge.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/Broker.h 1493903 /trunk/qpid/cpp/src/qpid/broker/Broker.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/Connection.h 1493903 /trunk/qpid/cpp/src/qpid/broker/Connection.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/ConnectionHandler.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/ConnectionState.h 1493903 /trunk/qpid/cpp/src/qpid/broker/ConnectionState.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/ConnectionToken.h 1493903 /trunk/qpid/cpp/src/qpid/broker/HandlerImpl.h 1493903 /trunk/qpid/cpp/src/qpid/broker/Message.h 1493903 /trunk/qpid/cpp/src/qpid/broker/Message.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/OwnershipToken.h 1493903 /trunk/qpid/cpp/src/qpid/broker/Publisher.h PRE-CREATION /trunk/qpid/cpp/src/qpid/broker/Queue.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/SaslAuthenticator.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/SemanticState.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/SessionAdapter.h 1493903 /trunk/qpid/cpp/src/qpid/broker/SessionAdapter.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/SessionContext.h 1493903 /trunk/qpid/cpp/src/qpid/broker/SessionHandler.h 1493903 /trunk/qpid/cpp/src/qpid/broker/SessionHandler.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/SessionState.h 1493903 /trunk/qpid/cpp/src/qpid/broker/SessionState.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/amqp/ManagedConnection.h 1493903 /trunk/qpid/cpp/src/qpid/broker/amqp/ManagedConnection.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/amqp/ManagedSession.h 1493903 /trunk/qpid/cpp/src/qpid/broker/amqp/ManagedSession.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/windows/SaslAuthenticator.cpp 1493903 /trunk/qpid/cpp/src/qpid/ha/ReplicatingSubscription.cpp 1493903 /trunk/qpid/cpp/src/qpid/management/ManagementAgent.h 1493903 /trunk/qpid/cpp/src/qpid/management/ManagementAgent.cpp 1493903 /trunk/qpid/cpp/src/qpid/sys/ConnectionOutputHandlerPtr.h 1493903 Diff: https://reviews.apache.org/r/11944/diff/ Testing --- cmake: make test Thanks, Andrew Stitcher
Re: Review Request: Continuation of Qpid C++ spring cleaning - QPID-4905
On June 18, 2013, 9:08 p.m., Andrew Stitcher wrote: I'm not especially attached the the terminology Publisher, it comes from the pre-existing setPublisher() method on the Message. However, the purpose of this object is certainly to do with Authentication and Ownership of the thing that is publishing the message, Gordon Sim wrote: I think Publisher is a very poor name. At present that interface defines connection identity, with the identification of the publishing connection being the only concrete use. It could however just as well be used to identify the declaring connection for a queue. That said, I am going to be doing work to separate some of the protocol independent stuff from the 0-10 connection anyway and would rather this gets committed so I can move on. I may change the name o f that interface as part of that. Andrew Stitcher wrote: I could certainly change the interfce name to ConnectionIdentity if you prefer. I certainly think that would be a better name. - Gordon --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11944/#review22074 --- On June 18, 2013, 9:06 p.m., Andrew Stitcher wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11944/ --- (Updated June 18, 2013, 9:06 p.m.) Review request for qpid and Gordon Sim. Description --- This is a continuation of review 11628 - https://reviews.apache.org/r/11628/ Included in this review is the last change there merging broker::Connection and broker::ConnectionState and a further change that tidies up the interface of the Connection/Message classes to the Broker management code. This introduces a protocol independent Publisher interface that can be queried for the userID/Url/ObjectId and OwnershipToken of a message publisher. This is used primarily in authenticating management messages. This addresses bug QPID-4905. https://issues.apache.org/jira/browse/QPID-4905 Diffs - /trunk/qpid/cpp/src/CMakeLists.txt 1493903 /trunk/qpid/cpp/src/Makefile.am 1493903 /trunk/qpid/cpp/src/qpid/broker/Bridge.h 1493903 /trunk/qpid/cpp/src/qpid/broker/Bridge.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/Broker.h 1493903 /trunk/qpid/cpp/src/qpid/broker/Broker.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/Connection.h 1493903 /trunk/qpid/cpp/src/qpid/broker/Connection.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/ConnectionHandler.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/ConnectionState.h 1493903 /trunk/qpid/cpp/src/qpid/broker/ConnectionState.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/ConnectionToken.h 1493903 /trunk/qpid/cpp/src/qpid/broker/HandlerImpl.h 1493903 /trunk/qpid/cpp/src/qpid/broker/Message.h 1493903 /trunk/qpid/cpp/src/qpid/broker/Message.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/OwnershipToken.h 1493903 /trunk/qpid/cpp/src/qpid/broker/Publisher.h PRE-CREATION /trunk/qpid/cpp/src/qpid/broker/Queue.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/SaslAuthenticator.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/SemanticState.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/SessionAdapter.h 1493903 /trunk/qpid/cpp/src/qpid/broker/SessionAdapter.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/SessionContext.h 1493903 /trunk/qpid/cpp/src/qpid/broker/SessionHandler.h 1493903 /trunk/qpid/cpp/src/qpid/broker/SessionHandler.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/SessionState.h 1493903 /trunk/qpid/cpp/src/qpid/broker/SessionState.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/amqp/ManagedConnection.h 1493903 /trunk/qpid/cpp/src/qpid/broker/amqp/ManagedConnection.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/amqp/ManagedSession.h 1493903 /trunk/qpid/cpp/src/qpid/broker/amqp/ManagedSession.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/windows/SaslAuthenticator.cpp 1493903 /trunk/qpid/cpp/src/qpid/ha/ReplicatingSubscription.cpp 1493903 /trunk/qpid/cpp/src/qpid/management/ManagementAgent.h 1493903 /trunk/qpid/cpp/src/qpid/management/ManagementAgent.cpp 1493903 /trunk/qpid/cpp/src/qpid/sys/ConnectionOutputHandlerPtr.h 1493903 Diff: https://reviews.apache.org/r/11944/diff/ Testing --- cmake: make test Thanks, Andrew Stitcher
[jira] [Created] (QPID-4936) QMF reporting differs when creating federation with --credit 0 and leaving the default
Zdenek Kraus created QPID-4936: -- Summary: QMF reporting differs when creating federation with --credit 0 and leaving the default Key: QPID-4936 URL: https://issues.apache.org/jira/browse/QPID-4936 Project: Qpid Issue Type: Bug Components: Qpid Managment Framework Affects Versions: 0.22, 0.23 Environment: environment independent Reporter: Zdenek Kraus Assignee: Ted Ross When you create a route without specifying the credit value (credit should be not applied (=unlimited)) the QMF reports the credit on the bridge object as 2^32 thus unlimited. But the other case, when you specify the --credit=0, result should be the same (=unlimited), the QMF in this case reports a zero credit. How reproducible: 100% Steps to Reproduce: 1. create a federation route without specifying a credit value 2. create another federation route with the credit specified --credit 0 3. check with the qpid-tool the credit value set Actual results: # DEFAULT # Object of type: org.apache.qpid.broker:bridge:_data(b71da3c2-cbac-950f-1954-2aeced85659e) Attribute 165 == linkRef 178 nameqpid.tcp:192.168.6.3:5672!dq!ex! channelId 2 durable False src dq destex key srcIsQueue True srcIsLocal False tag excludes dynamic False sync1 credit 4294967295 # CREDIT # Object of type: org.apache.qpid.broker:bridge:_data(b71da3c2-cbac-950f-1954-2aeced85659e) Attribute 188 == linkRef 201 nameqpid.tcp:192.168.6.3:5672!dq!ex! channelId 3 durable False src dq destex key srcIsQueue True srcIsLocal False tag excludes dynamic False sync1 credit 0 Expected results: the QMF reports the same value for both ways, preferably zero (same as --ack/sync option) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-4936) QMF reporting differs when creating federation with --credit 0 and leaving the default
[ https://issues.apache.org/jira/browse/QPID-4936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned QPID-4936: Assignee: Ken Giusti (was: Ted Ross) QMF reporting differs when creating federation with --credit 0 and leaving the default -- Key: QPID-4936 URL: https://issues.apache.org/jira/browse/QPID-4936 Project: Qpid Issue Type: Bug Components: Qpid Managment Framework Affects Versions: 0.22, 0.23 Environment: environment independent Reporter: Zdenek Kraus Assignee: Ken Giusti When you create a route without specifying the credit value (credit should be not applied (=unlimited)) the QMF reports the credit on the bridge object as 2^32 thus unlimited. But the other case, when you specify the --credit=0, result should be the same (=unlimited), the QMF in this case reports a zero credit. How reproducible: 100% Steps to Reproduce: 1. create a federation route without specifying a credit value 2. create another federation route with the credit specified --credit 0 3. check with the qpid-tool the credit value set Actual results: # DEFAULT # Object of type: org.apache.qpid.broker:bridge:_data(b71da3c2-cbac-950f-1954-2aeced85659e) Attribute 165 == linkRef 178 nameqpid.tcp:192.168.6.3:5672!dq!ex! channelId 2 durable False src dq destex key srcIsQueue True srcIsLocal False tag excludes dynamic False sync1 credit 4294967295 # CREDIT # Object of type: org.apache.qpid.broker:bridge:_data(b71da3c2-cbac-950f-1954-2aeced85659e) Attribute 188 == linkRef 201 nameqpid.tcp:192.168.6.3:5672!dq!ex! channelId 3 durable False src dq destex key srcIsQueue True srcIsLocal False tag excludes dynamic False sync1 credit 0 Expected results: the QMF reports the same value for both ways, preferably zero (same as --ack/sync option) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4933) The qpid_messaging gem does not install on Ruby greater than 1.8.7
[ https://issues.apache.org/jira/browse/QPID-4933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13688016#comment-13688016 ] ASF subversion and git services commented on QPID-4933: --- Commit 1494628 from [~mcpierce] [ https://svn.apache.org/r1494628 ] QPID-4933: Fix Ruby gem installs on Ruby 1.8.7 Changed the cqpid extconf.rb file to use different command line options depending on which version of Ruby is installing the gem. The qpid_messaging gem does not install on Ruby greater than 1.8.7 -- Key: QPID-4933 URL: https://issues.apache.org/jira/browse/QPID-4933 Project: Qpid Issue Type: Bug Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce Priority: Blocker Fix For: 0.23 When installing on Ruby 1.9.7 or 2.0.0 the gem fails to find the C++ libraries. The issue appears to be command line options passed as part of generating the Makefile with mkmfs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4936) QMF reporting differs when creating federation with --credit 0 and leaving the default
[ https://issues.apache.org/jira/browse/QPID-4936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated QPID-4936: --- Component/s: (was: Qpid Managment Framework) C++ Broker QMF reporting differs when creating federation with --credit 0 and leaving the default -- Key: QPID-4936 URL: https://issues.apache.org/jira/browse/QPID-4936 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.22, 0.23 Environment: environment independent Reporter: Zdenek Kraus Assignee: Ken Giusti When you create a route without specifying the credit value (credit should be not applied (=unlimited)) the QMF reports the credit on the bridge object as 2^32 thus unlimited. But the other case, when you specify the --credit=0, result should be the same (=unlimited), the QMF in this case reports a zero credit. How reproducible: 100% Steps to Reproduce: 1. create a federation route without specifying a credit value 2. create another federation route with the credit specified --credit 0 3. check with the qpid-tool the credit value set Actual results: # DEFAULT # Object of type: org.apache.qpid.broker:bridge:_data(b71da3c2-cbac-950f-1954-2aeced85659e) Attribute 165 == linkRef 178 nameqpid.tcp:192.168.6.3:5672!dq!ex! channelId 2 durable False src dq destex key srcIsQueue True srcIsLocal False tag excludes dynamic False sync1 credit 4294967295 # CREDIT # Object of type: org.apache.qpid.broker:bridge:_data(b71da3c2-cbac-950f-1954-2aeced85659e) Attribute 188 == linkRef 201 nameqpid.tcp:192.168.6.3:5672!dq!ex! channelId 3 durable False src dq destex key srcIsQueue True srcIsLocal False tag excludes dynamic False sync1 credit 0 Expected results: the QMF reports the same value for both ways, preferably zero (same as --ack/sync option) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4905) C++ Broker/common code needs tidying up of obsolete/unused code
[ https://issues.apache.org/jira/browse/QPID-4905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13688035#comment-13688035 ] ASF subversion and git services commented on QPID-4905: --- Commit 1494640 from [~astitcher] [ https://svn.apache.org/r1494640 ] QPID-4905: Stopped broker::Broker needing to refer to broker::Connection - Also removed ConnectionToken which didn't add anything over OwnershipToken C++ Broker/common code needs tidying up of obsolete/unused code --- Key: QPID-4905 URL: https://issues.apache.org/jira/browse/QPID-4905 Project: Qpid Issue Type: Improvement Components: C++ Broker, C++ Client Reporter: Andrew Stitcher Assignee: Andrew Stitcher There is quite a lot of code in the Qpid C++ code base that is vestigial (like your appendix). In the name of easier code maintenance we should remove it. I will detail some of the things I have found as comments to this JIRA, if they attract sufficient comment they can be broken out as subtasks to this issue. Most of these issues are small and involve unused member functions or unused/potentially unused interfaces or interfaces implemented unnecessarily. Much of this is still the fallout of removing the old cluster work which added hook (and hence interfaces) in lots of code, now that old cluster is gone the interfaces/members remain, but are unused anywhere. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4905) C++ Broker/common code needs tidying up of obsolete/unused code
[ https://issues.apache.org/jira/browse/QPID-4905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13688034#comment-13688034 ] ASF subversion and git services commented on QPID-4905: --- Commit 1494639 from [~astitcher] [ https://svn.apache.org/r1494639 ] QPID-4905: Tidy up broker::Connection - Clean up code for accounting for sent frames - merged Connection and ConnectionState into Connection C++ Broker/common code needs tidying up of obsolete/unused code --- Key: QPID-4905 URL: https://issues.apache.org/jira/browse/QPID-4905 Project: Qpid Issue Type: Improvement Components: C++ Broker, C++ Client Reporter: Andrew Stitcher Assignee: Andrew Stitcher There is quite a lot of code in the Qpid C++ code base that is vestigial (like your appendix). In the name of easier code maintenance we should remove it. I will detail some of the things I have found as comments to this JIRA, if they attract sufficient comment they can be broken out as subtasks to this issue. Most of these issues are small and involve unused member functions or unused/potentially unused interfaces or interfaces implemented unnecessarily. Much of this is still the fallout of removing the old cluster work which added hook (and hence interfaces) in lots of code, now that old cluster is gone the interfaces/members remain, but are unused anywhere. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-4905) C++ Broker/common code needs tidying up of obsolete/unused code
[ https://issues.apache.org/jira/browse/QPID-4905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved QPID-4905. --- Resolution: Fixed Fix Version/s: 0.23 C++ Broker/common code needs tidying up of obsolete/unused code --- Key: QPID-4905 URL: https://issues.apache.org/jira/browse/QPID-4905 Project: Qpid Issue Type: Improvement Components: C++ Broker, C++ Client Reporter: Andrew Stitcher Assignee: Andrew Stitcher Fix For: 0.23 There is quite a lot of code in the Qpid C++ code base that is vestigial (like your appendix). In the name of easier code maintenance we should remove it. I will detail some of the things I have found as comments to this JIRA, if they attract sufficient comment they can be broken out as subtasks to this issue. Most of these issues are small and involve unused member functions or unused/potentially unused interfaces or interfaces implemented unnecessarily. Much of this is still the fallout of removing the old cluster work which added hook (and hence interfaces) in lots of code, now that old cluster is gone the interfaces/members remain, but are unused anywhere. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Review Request: Continuation of Qpid C++ spring cleaning - QPID-4905
On June 18, 2013, 9:08 p.m., Andrew Stitcher wrote: I'm not especially attached the the terminology Publisher, it comes from the pre-existing setPublisher() method on the Message. However, the purpose of this object is certainly to do with Authentication and Ownership of the thing that is publishing the message, Gordon Sim wrote: I think Publisher is a very poor name. At present that interface defines connection identity, with the identification of the publishing connection being the only concrete use. It could however just as well be used to identify the declaring connection for a queue. That said, I am going to be doing work to separate some of the protocol independent stuff from the 0-10 connection anyway and would rather this gets committed so I can move on. I may change the name o f that interface as part of that. Andrew Stitcher wrote: I could certainly change the interfce name to ConnectionIdentity if you prefer. Gordon Sim wrote: I certainly think that would be a better name. I've now committed this change with the interface name ConnectionIdentity - Andrew --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11944/#review22074 --- On June 18, 2013, 9:06 p.m., Andrew Stitcher wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11944/ --- (Updated June 18, 2013, 9:06 p.m.) Review request for qpid and Gordon Sim. Description --- This is a continuation of review 11628 - https://reviews.apache.org/r/11628/ Included in this review is the last change there merging broker::Connection and broker::ConnectionState and a further change that tidies up the interface of the Connection/Message classes to the Broker management code. This introduces a protocol independent Publisher interface that can be queried for the userID/Url/ObjectId and OwnershipToken of a message publisher. This is used primarily in authenticating management messages. This addresses bug QPID-4905. https://issues.apache.org/jira/browse/QPID-4905 Diffs - /trunk/qpid/cpp/src/CMakeLists.txt 1493903 /trunk/qpid/cpp/src/Makefile.am 1493903 /trunk/qpid/cpp/src/qpid/broker/Bridge.h 1493903 /trunk/qpid/cpp/src/qpid/broker/Bridge.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/Broker.h 1493903 /trunk/qpid/cpp/src/qpid/broker/Broker.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/Connection.h 1493903 /trunk/qpid/cpp/src/qpid/broker/Connection.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/ConnectionHandler.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/ConnectionState.h 1493903 /trunk/qpid/cpp/src/qpid/broker/ConnectionState.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/ConnectionToken.h 1493903 /trunk/qpid/cpp/src/qpid/broker/HandlerImpl.h 1493903 /trunk/qpid/cpp/src/qpid/broker/Message.h 1493903 /trunk/qpid/cpp/src/qpid/broker/Message.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/OwnershipToken.h 1493903 /trunk/qpid/cpp/src/qpid/broker/Publisher.h PRE-CREATION /trunk/qpid/cpp/src/qpid/broker/Queue.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/SaslAuthenticator.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/SemanticState.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/SessionAdapter.h 1493903 /trunk/qpid/cpp/src/qpid/broker/SessionAdapter.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/SessionContext.h 1493903 /trunk/qpid/cpp/src/qpid/broker/SessionHandler.h 1493903 /trunk/qpid/cpp/src/qpid/broker/SessionHandler.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/SessionState.h 1493903 /trunk/qpid/cpp/src/qpid/broker/SessionState.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/amqp/ManagedConnection.h 1493903 /trunk/qpid/cpp/src/qpid/broker/amqp/ManagedConnection.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/amqp/ManagedSession.h 1493903 /trunk/qpid/cpp/src/qpid/broker/amqp/ManagedSession.cpp 1493903 /trunk/qpid/cpp/src/qpid/broker/windows/SaslAuthenticator.cpp 1493903 /trunk/qpid/cpp/src/qpid/ha/ReplicatingSubscription.cpp 1493903 /trunk/qpid/cpp/src/qpid/management/ManagementAgent.h 1493903 /trunk/qpid/cpp/src/qpid/management/ManagementAgent.cpp 1493903 /trunk/qpid/cpp/src/qpid/sys/ConnectionOutputHandlerPtr.h 1493903 Diff: https://reviews.apache.org/r/11944/diff/ Testing --- cmake: make test Thanks, Andrew Stitcher
[jira] [Commented] (QPID-4854) max-negotiate-time feature breaks AMQP 1.0 (and arguably doesn't achieve the desired objective anyway)
[ https://issues.apache.org/jira/browse/QPID-4854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13688048#comment-13688048 ] ASF subversion and git services commented on QPID-4854: --- Commit 1494645 from [~gsim] [ https://svn.apache.org/r1494645 ] QPID-4854: signal connection establishment for broker initiated connections also max-negotiate-time feature breaks AMQP 1.0 (and arguably doesn't achieve the desired objective anyway) -- Key: QPID-4854 URL: https://issues.apache.org/jira/browse/QPID-4854 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.20, 0.22 Reporter: Gordon Sim Assignee: Andrew Stitcher Fix For: 0.23 It has assumptions based on 0-10 (and a particular pattern for 0-10 at that) built into the underlying transport code (which should be protocol agnostic). As AMQP 1.0 makes it much simpler and more likely for less synchronous handshaking, the '3 reads' magic doesn't work and causes 1.0 connections to be terminated incorrectly. Either the original solution needs to be reimplemented or it needs to be possible to disable it for use with 1.0. See QPID-4021 and QPID-2518. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4935) [AMQP 1.0] sender expects messages to always be accepted
[ https://issues.apache.org/jira/browse/QPID-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13688047#comment-13688047 ] ASF subversion and git services commented on QPID-4935: --- Commit 1494644 from [~gsim] [ https://svn.apache.org/r1494644 ] QPID-4935: handle case where peer to sender settles without setting a delivery state [AMQP 1.0] sender expects messages to always be accepted Key: QPID-4935 URL: https://issues.apache.org/jira/browse/QPID-4935 Project: Qpid Issue Type: Improvement Components: C++ Client Affects Versions: 0.22 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.23 If they are settled without any state being set, then closing or syncing the sender/session will hang. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Website update 6
On Wed, Jun 19, 2013 at 7:17 AM, Robbie Gemmell robbie.gemm...@gmail.com wrote: Hi Justin, I had a quick lookand noticed a few issues: The site can't be used at all in IE8 as it loads up in XML view. This seems like a blocker to me, as IE8 is apparently still one of the most used browsers. I've added an attempted fix, a meta header that the internet says may have a positive effect. Unfortunately, right now I don't have access to IE8; I can try to install it tomorrow. Could you give the head site another try and let me know if there's any change? The JCA download link on http://people.apache.org/~jross/transom/head/download.html is pointing at the Java broker archive. I mistakenly thought it was in the broker jar. I've corrected it now to point at the qpid-java-$version artifact, since that's the one place I found it, apart from the big source distro. Some of the Features links are broken on the Java broker component page: http://people.apache.org/~jross/transom/head/components/java-broker/index.html Fixed. The download links on the newer individual release pages (e.g http://people.apache.org/~jross/transom/head/releases/qpid-0.22/index.htmland http://people.apache.org/~jross/transom/head/releases/qpid-proton-0.4/index.html) are linking directly to www.apache.org/dist instead of using the mirror system like the main download page does. Fixed. Justin - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-4935) [AMQP 1.0] sender expects messages to always be accepted
[ https://issues.apache.org/jira/browse/QPID-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved QPID-4935. -- Resolution: Fixed [AMQP 1.0] sender expects messages to always be accepted Key: QPID-4935 URL: https://issues.apache.org/jira/browse/QPID-4935 Project: Qpid Issue Type: Improvement Components: C++ Client Affects Versions: 0.22 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.23 If they are settled without any state being set, then closing or syncing the sender/session will hang. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Website update 6
On 19 June 2013 16:58, Justin Ross justin.r...@gmail.com wrote: On Wed, Jun 19, 2013 at 7:17 AM, Robbie Gemmell robbie.gemm...@gmail.com wrote: Hi Justin, I had a quick lookand noticed a few issues: The site can't be used at all in IE8 as it loads up in XML view. This seems like a blocker to me, as IE8 is apparently still one of the most used browsers. I've added an attempted fix, a meta header that the internet says may have a positive effect. Unfortunately, right now I don't have access to IE8; I can try to install it tomorrow. Could you give the head site another try and let me know if there's any change? Nope - still seems to be broken :-( -- Rob The JCA download link on http://people.apache.org/~jross/transom/head/download.html is pointing at the Java broker archive. I mistakenly thought it was in the broker jar. I've corrected it now to point at the qpid-java-$version artifact, since that's the one place I found it, apart from the big source distro. Some of the Features links are broken on the Java broker component page: http://people.apache.org/~jross/transom/head/components/java-broker/index.html Fixed. The download links on the newer individual release pages (e.g http://people.apache.org/~jross/transom/head/releases/qpid-0.22/index.htmland http://people.apache.org/~jross/transom/head/releases/qpid-proton-0.4/index.html ) are linking directly to www.apache.org/dist instead of using the mirror system like the main download page does. Fixed. Justin - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: [VOTE] Replace the Qpid website
[ X ] Yes, replace the existing site with the proposed site [ ] No, the proposed site isn't ready - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4931) Broker should only listen to a single network address if --port 0 is specified
[ https://issues.apache.org/jira/browse/QPID-4931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13688073#comment-13688073 ] ASF subversion and git services commented on QPID-4931: --- Commit 1494656 from [~astitcher] [ https://svn.apache.org/r1494656 ] QPID-4931: Only allow broker to listen to a single address if --port 0 specified - If more than one address is specified or implied by the defaults the broker will log a warning - This is intended to avoid testing problems where the broker fails to connect to the port of subsequent listening addresses Broker should only listen to a single network address if --port 0 is specified Key: QPID-4931 URL: https://issues.apache.org/jira/browse/QPID-4931 Project: Qpid Issue Type: Improvement Components: C++ Broker Reporter: Andrew Stitcher Assignee: Andrew Stitcher The C++ broker has a setting which is really only useful for testing which allows the broker to listen to whichever port the kernel gives it. In this mode it prints the received port on stdout for subsequent testing programs to use. When you listen to multiple network addresses (addresses are multiple network interfaces or multiple protocols on the same network interface - IPv4 IPv6 for example) the broker has to remember the port it got for the first address and then try to get the same port for subsequent addresses. Unfortunately there is no guarantee that the same port will actually be available on the other addresses so the entire broker startup can fail. In the testing environment which this is useful for you only care about the IPv4 loopback address in any case so we have to ensure that this address is the only (or at least the first) address used. Because we can't guarantee getting the same port for more than one address it makes sense to restrict --port 0 to only listening to a single address. I propose that if the broker detects that more than one address has been specified or is implied by the network setup it should list to the first address and log a warning message with the actual address listened to. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-4931) Broker should only listen to a single network address if --port 0 is specified
[ https://issues.apache.org/jira/browse/QPID-4931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved QPID-4931. --- Resolution: Fixed Fix Version/s: 0.23 Broker should only listen to a single network address if --port 0 is specified Key: QPID-4931 URL: https://issues.apache.org/jira/browse/QPID-4931 Project: Qpid Issue Type: Improvement Components: C++ Broker Reporter: Andrew Stitcher Assignee: Andrew Stitcher Fix For: 0.23 The C++ broker has a setting which is really only useful for testing which allows the broker to listen to whichever port the kernel gives it. In this mode it prints the received port on stdout for subsequent testing programs to use. When you listen to multiple network addresses (addresses are multiple network interfaces or multiple protocols on the same network interface - IPv4 IPv6 for example) the broker has to remember the port it got for the first address and then try to get the same port for subsequent addresses. Unfortunately there is no guarantee that the same port will actually be available on the other addresses so the entire broker startup can fail. In the testing environment which this is useful for you only care about the IPv4 loopback address in any case so we have to ensure that this address is the only (or at least the first) address used. Because we can't guarantee getting the same port for more than one address it makes sense to restrict --port 0 to only listening to a single address. I propose that if the broker detects that more than one address has been specified or is implied by the network setup it should list to the first address and log a warning message with the actual address listened to. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-4937) [Java Broker] Separate virtual host implementations into different types
Rob Godfrey created QPID-4937: - Summary: [Java Broker] Separate virtual host implementations into different types Key: QPID-4937 URL: https://issues.apache.org/jira/browse/QPID-4937 Project: Qpid Issue Type: Bug Components: Java Broker Reporter: Rob Godfrey Assignee: Rob Godfrey Fix For: 0.23 Replicating virtual hosts have different lifecycle properties to non-replicating virtual hosts. moreover different replication, storage and group leader election strategies may be employed by different implementations. Currently HA functionality - and in particular master election - is only able to be provided by the store (in line with how the BDB HA solution works). Instead we should make replication and failover a property of the virtual host and allow alternative implementations with alternative strategies -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4937) [Java Broker] Separate virtual host implementations into different types
[ https://issues.apache.org/jira/browse/QPID-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-4937: -- Issue Type: Improvement (was: Bug) [Java Broker] Separate virtual host implementations into different types Key: QPID-4937 URL: https://issues.apache.org/jira/browse/QPID-4937 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Rob Godfrey Assignee: Rob Godfrey Fix For: 0.23 Replicating virtual hosts have different lifecycle properties to non-replicating virtual hosts. moreover different replication, storage and group leader election strategies may be employed by different implementations. Currently HA functionality - and in particular master election - is only able to be provided by the store (in line with how the BDB HA solution works). Instead we should make replication and failover a property of the virtual host and allow alternative implementations with alternative strategies -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4937) [Java Broker] Separate virtual host implementations into different types
[ https://issues.apache.org/jira/browse/QPID-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13688086#comment-13688086 ] ASF subversion and git services commented on QPID-4937: --- Commit 1494667 from [~godfrer] [ https://svn.apache.org/r1494667 ] QPID-4937 : [Java Broker] separate virtualhosts into different types [Java Broker] Separate virtual host implementations into different types Key: QPID-4937 URL: https://issues.apache.org/jira/browse/QPID-4937 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Rob Godfrey Assignee: Rob Godfrey Fix For: 0.23 Replicating virtual hosts have different lifecycle properties to non-replicating virtual hosts. moreover different replication, storage and group leader election strategies may be employed by different implementations. Currently HA functionality - and in particular master election - is only able to be provided by the store (in line with how the BDB HA solution works). Instead we should make replication and failover a property of the virtual host and allow alternative implementations with alternative strategies -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-4938) Stop build ssl and acl support as separate plugin modules on Unix
Andrew Stitcher created QPID-4938: - Summary: Stop build ssl and acl support as separate plugin modules on Unix Key: QPID-4938 URL: https://issues.apache.org/jira/browse/QPID-4938 Project: Qpid Issue Type: Improvement Components: C++ Broker, C++ Client Reporter: Andrew Stitcher There seems to be no strong reason we build these features as separate modules: ACLs are a fundamental feature of a broker that does any sort of authentication so having to load a module to enforce them seems strange. SSL is a feature that any modern server/client should support if possible. Note that under windows neither of these is built as a plugin. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: C++ Broker use of --port 0 option
+1 On 06/17/2013 06:42 PM, Andrew Stitcher wrote: I've just opened QPID-4931[1] and a code review [2] to change the behaviour of the --port 0 command line option to the C++ broker. Essentially if you use this option after the change the broker will only listen to a single address and you will need to use --interface to select the address you require. This option is only really useful for testing purposes and so I don't expect this to have very much impact, but please do speak up if you use this option for some purpose that I can't imagine and will be affected by this change. Note that in the future I'd like to entirely get rid of this option and replace its uses with the --socket-fd option and the work that Alan has done [3]. I'd like to get this in for 0.24 so speak up soon. Thanks Andrew [1] https://issues.apache.org/jira/browse/QPID-4931 [2] https://reviews.apache.org/r/11915/ [3] https://reviews.apache.org/r/10872/ - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4938) Stop build ssl and acl support as separate plugin modules on Unix
[ https://issues.apache.org/jira/browse/QPID-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13688167#comment-13688167 ] ASF subversion and git services commented on QPID-4938: --- Commit 1494697 from [~astitcher] [ https://svn.apache.org/r1494697 ] QPID-4938: No longer build acl or ssl support as plugins (also remove final references to dead watchdog plugin) Stop build ssl and acl support as separate plugin modules on Unix - Key: QPID-4938 URL: https://issues.apache.org/jira/browse/QPID-4938 Project: Qpid Issue Type: Improvement Components: C++ Broker, C++ Client Reporter: Andrew Stitcher There seems to be no strong reason we build these features as separate modules: ACLs are a fundamental feature of a broker that does any sort of authentication so having to load a module to enforce them seems strange. SSL is a feature that any modern server/client should support if possible. Note that under windows neither of these is built as a plugin. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4905) C++ Broker/common code needs tidying up of obsolete/unused code
[ https://issues.apache.org/jira/browse/QPID-4905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13688183#comment-13688183 ] ASF subversion and git services commented on QPID-4905: --- Commit 1494700 from [~astitcher] [ https://svn.apache.org/r1494700 ] QPID-4905: Add needed virtual destructor missed earlier C++ Broker/common code needs tidying up of obsolete/unused code --- Key: QPID-4905 URL: https://issues.apache.org/jira/browse/QPID-4905 Project: Qpid Issue Type: Improvement Components: C++ Broker, C++ Client Reporter: Andrew Stitcher Assignee: Andrew Stitcher Fix For: 0.23 There is quite a lot of code in the Qpid C++ code base that is vestigial (like your appendix). In the name of easier code maintenance we should remove it. I will detail some of the things I have found as comments to this JIRA, if they attract sufficient comment they can be broken out as subtasks to this issue. Most of these issues are small and involve unused member functions or unused/potentially unused interfaces or interfaces implemented unnecessarily. Much of this is still the fallout of removing the old cluster work which added hook (and hence interfaces) in lots of code, now that old cluster is gone the interfaces/members remain, but are unused anywhere. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4931) Broker should only listen to a single network address if --port 0 is specified
[ https://issues.apache.org/jira/browse/QPID-4931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13688225#comment-13688225 ] ASF subversion and git services commented on QPID-4931: --- Commit 1494712 from [~astitcher] [ https://svn.apache.org/r1494712 ] QPID-4931: Remove removed member function from windows SocketAddress code too. While there bring this code up to date with other recent changes to the POSIX equivalent code. Broker should only listen to a single network address if --port 0 is specified Key: QPID-4931 URL: https://issues.apache.org/jira/browse/QPID-4931 Project: Qpid Issue Type: Improvement Components: C++ Broker Reporter: Andrew Stitcher Assignee: Andrew Stitcher Fix For: 0.23 The C++ broker has a setting which is really only useful for testing which allows the broker to listen to whichever port the kernel gives it. In this mode it prints the received port on stdout for subsequent testing programs to use. When you listen to multiple network addresses (addresses are multiple network interfaces or multiple protocols on the same network interface - IPv4 IPv6 for example) the broker has to remember the port it got for the first address and then try to get the same port for subsequent addresses. Unfortunately there is no guarantee that the same port will actually be available on the other addresses so the entire broker startup can fail. In the testing environment which this is useful for you only care about the IPv4 loopback address in any case so we have to ensure that this address is the only (or at least the first) address used. Because we can't guarantee getting the same port for more than one address it makes sense to restrict --port 0 to only listening to a single address. I propose that if the broker detects that more than one address has been specified or is implied by the network setup it should list to the first address and log a warning message with the actual address listened to. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4938) Stop building ssl and acl support as separate plugin modules on Unix
[ https://issues.apache.org/jira/browse/QPID-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-4938: -- Summary: Stop building ssl and acl support as separate plugin modules on Unix (was: Stop build ssl and acl support as separate plugin modules on Unix) Stop building ssl and acl support as separate plugin modules on Unix Key: QPID-4938 URL: https://issues.apache.org/jira/browse/QPID-4938 Project: Qpid Issue Type: Improvement Components: C++ Broker, C++ Client Reporter: Andrew Stitcher There seems to be no strong reason we build these features as separate modules: ACLs are a fundamental feature of a broker that does any sort of authentication so having to load a module to enforce them seems strange. SSL is a feature that any modern server/client should support if possible. Note that under windows neither of these is built as a plugin. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-4939) Provide a CMake build file for the Perl language bindings
Darryl L. Pierce created QPID-4939: -- Summary: Provide a CMake build file for the Perl language bindings Key: QPID-4939 URL: https://issues.apache.org/jira/browse/QPID-4939 Project: Qpid Issue Type: Improvement Components: Perl Client Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce Priority: Minor To make it easier to build the bindings, a cross-platform build file should be included with the sources. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: QPID code reorg/cleanups - please read.
On 18/06/13 23:30, Ken Giusti wrote:
Folks,
There's some old QMF-related code in our repo that appears to be quite dead.
If said code is in fact pushing up the daisies, I'd like to see removed prior
to the 0.24 release.
First, there's stuff that I'm almost certain is stone cold dead. AFAIK, this
shouldn't be used by anyone. It certainly isn't being maintained.
Specifically:
qpid/extras/qmf/src/py/qmf2-prototype - experimental stuff done while
developing QMFv2.
I suspect that you are correct that it's not used by anyone, though I'd
quip that's because as a community we've not done a terribly good job so
far of providing a cohesive unified approach to AMQP management - though
of course anyone who reads my posts knows my views on that already :-)
FWIW I don't tend to use python for anything more than tinkering so it
won't have an operational affect on me, however I will say that I'd got
something of a soft spot for that particular bit of code, because it's
the only bot of QMF2 other than the Java stuff that I put together that
actually follows the only publicly published QMF2 API :-) so I felt a
certain sense of strengh in that... For better or worse I actually far
prefer that to the qpidtoollibs library that sprung up to replace the
original QMF1 library for the standard tools, qpidtoollibs to my eye
feels like it organically evolved a little - sure it's made a big
difference to qpid-config et al but it feels less of a structured API
than the one in qmf2-prototype.
It's all a bit moot of course and if nobody is using it I won't stand in
the way, though perhaps we should leave it rotting in a gibbet to
provide a lesson from history that we must try harder next time :-)
You see - any time anyone mentions QMF2 I end up going off on one :-D
qpid/cpp/{include,src}/qmf/engine - an attempt to re-write QMFv1 in C++.
qpid/cpp/bindings/qmf - multi-language bindings for the above 'engine' code
Seems fair to kill this.
There's other stuff that appears to have shuffled off the mortal coil, but may
simply be in a deep coma [1]. These would be the old QMFv1 agent and console
libraries:
qpid/cpp/{include, src}/qpid/agent
qpid/cpp/{include, src}/qpid/console
Anyone still using these libraries?
I'm not, but I wonder if these need the fair warning approach that
seems to have been fairly well supported in the discussions around
removing automake and moving to cmake. Given all of the discussions that
exploded after the initial abortive attempt to rationalise the QMF1
stuff in the asynchronous python API and the realisation that it didn't
actually work for QMF2 and nobody had really noticed (most likely
because the broker Agent pushed both QMF1 and QMF2) I have a gnawing
feeling that there just may be more people using QMF1 than we
suspect/hope.
So how about
a) A few more warnings like this shouted out on the user list.
b) disabling it from building as the default and requiring an explicit
option
c) updating the doco to say it's in the departure lounge and will be
euthanised in 0.26
Thoughts?
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
Re: QPID code reorg/cleanups - please read.
On Wed, 2013-06-19 at 20:04 +0100, Fraser Adams wrote: On ... So how about a) A few more warnings like this shouted out on the user list. b) disabling it from building as the default and requiring an explicit option c) updating the doco to say it's in the departure lounge and will be euthanised in 0.26 Thoughts? In this case, I think that we should remove it preemptively. The discussion that Ken linked to was from January 2012 and the consensus then was along the same lines as his proposal (at least the way I read the consensus) with no dissent. I'd say that is enough warning. In the case of autotools - cmake we know that everyone was affected, and cmake had some catching up to do, so caution was sensible. In this case as far as we can tell no one is affected! In any case we are using source control and can revert the removal if we really have to. Andrew - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-4940) Remove unmaintained/obsolete QMF code
Andrew Stitcher created QPID-4940:
-
Summary: Remove unmaintained/obsolete QMF code
Key: QPID-4940
URL: https://issues.apache.org/jira/browse/QPID-4940
Project: Qpid
Issue Type: Improvement
Reporter: Andrew Stitcher
From email from Ken Giusti to \{users,dev\}@qpid.apache.org
There's some old QMF-related code in our repo that appears to be quite dead.
First, there's stuff that I'm almost certain is stone cold dead. AFAIK, this
shouldn't be used by anyone. It certainly isn't being maintained.
Specifically:
* qpid/extras/qmf/src/py/qmf2-prototype
** experimental stuff done while developing QMFv2.
* qpid/cpp/\{include,src\}/qmf/engine
** an attempt to re-write QMFv1 in C++.
* qpid/cpp/bindings/qmf
** multi-language bindings for the above 'engine' code
There's other stuff that appears to have shuffled off the mortal coil, but may
simply be in a deep coma. These would be the old QMFv1 agent and onsole
libraries:
* qpid/cpp/\{include,src\}/qpid/agent
* qpid/cpp/\{include,src\}/qpid/console
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4930) Provide upstream sources for Swigged Python APIs.
[ https://issues.apache.org/jira/browse/QPID-4930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13688360#comment-13688360 ] ASF subversion and git services commented on QPID-4930: --- Commit 1494752 from [~mcpierce] [ https://svn.apache.org/r1494752 ] QPID-4930: Create a Python swigged bindings source tarball. Created a README, LICENSE and ChangeLog file to be included. Added a CMakeLists.txt file that is included with the sources that can be used to build the Python bindings. Provide upstream sources for Swigged Python APIs. - Key: QPID-4930 URL: https://issues.apache.org/jira/browse/QPID-4930 Project: Qpid Issue Type: Improvement Components: Python Client Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce The current upstream sources are for the pure Python implementation. An upstream source that provides the swig descriptor and other files necessary to generate the bindings is needed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4930) Provide upstream sources for Swigged Python APIs.
[ https://issues.apache.org/jira/browse/QPID-4930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce updated QPID-4930: --- Fix Version/s: 0.23 Provide upstream sources for Swigged Python APIs. - Key: QPID-4930 URL: https://issues.apache.org/jira/browse/QPID-4930 Project: Qpid Issue Type: Improvement Components: Python Client Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce Fix For: 0.23 The current upstream sources are for the pure Python implementation. An upstream source that provides the swig descriptor and other files necessary to generate the bindings is needed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-4930) Provide upstream sources for Swigged Python APIs.
[
https://issues.apache.org/jira/browse/QPID-4930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darryl L. Pierce resolved QPID-4930.
Resolution: Fixed
The python target for release.sh now creates the file
python-qpid_messaging-${VER}.tar.gz that can be used to build the Python swig
bindings.
Provide upstream sources for Swigged Python APIs.
-
Key: QPID-4930
URL: https://issues.apache.org/jira/browse/QPID-4930
Project: Qpid
Issue Type: Improvement
Components: Python Client
Reporter: Darryl L. Pierce
Assignee: Darryl L. Pierce
Fix For: 0.23
The current upstream sources are for the pure Python implementation. An
upstream source that provides the swig descriptor and other files necessary
to generate the bindings is needed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
Re: QPID code reorg/cleanups - please read.
On Tue, 2013-06-18 at 18:30 -0400, Ken Giusti wrote: Folks, There's some old QMF-related code in our repo that appears to be quite dead. I've create a JIRA to track this work: https://issues.apache.org/jira/browse/QPID-4940 I'm in the mood to remove lots of code from the tree ;-), so I'll prepare a change for review and we can have a lighter tree soon. Andrew - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Website update 6
On Wed, Jun 19, 2013 at 11:01 AM, Rob Godfrey rob.j.godf...@gmail.com wrote: On 19 June 2013 16:58, Justin Ross justin.r...@gmail.com wrote: On Wed, Jun 19, 2013 at 7:17 AM, Robbie Gemmell robbie.gemm...@gmail.com wrote: Hi Justin, I had a quick lookand noticed a few issues: The site can't be used at all in IE8 as it loads up in XML view. This seems like a blocker to me, as IE8 is apparently still one of the most used browsers. I've added an attempted fix, a meta header that the internet says may have a positive effect. Unfortunately, right now I don't have access to IE8; I can try to install it tomorrow. Could you give the head site another try and let me know if there's any change? Nope - still seems to be broken :-( I believe I've got this fixed now. I removed the standard template's xml declaration. (It's still all xhtml). I used browsershots.org to render the page on many browser versions, since I don't have access to a windows machine today. With the latest change, it seems to render well enough all the way back to IE6. Justin - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4940) Remove unmaintained/obsolete QMF code
[
https://issues.apache.org/jira/browse/QPID-4940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher updated QPID-4940:
--
Assignee: Andrew Stitcher
Remove unmaintained/obsolete QMF code
-
Key: QPID-4940
URL: https://issues.apache.org/jira/browse/QPID-4940
Project: Qpid
Issue Type: Improvement
Reporter: Andrew Stitcher
Assignee: Andrew Stitcher
From email from Ken Giusti to \{users,dev\}@qpid.apache.org
There's some old QMF-related code in our repo that appears to be quite dead.
First, there's stuff that I'm almost certain is stone cold dead. AFAIK, this
shouldn't be used by anyone. It certainly isn't being maintained.
Specifically:
* qpid/extras/qmf/src/py/qmf2-prototype
** experimental stuff done while developing QMFv2.
* qpid/cpp/\{include,src\}/qmf/engine
** an attempt to re-write QMFv1 in C++.
* qpid/cpp/bindings/qmf
** multi-language bindings for the above 'engine' code
There's other stuff that appears to have shuffled off the mortal coil, but
may simply be in a deep coma. These would be the old QMFv1 agent and onsole
libraries:
* qpid/cpp/\{include,src\}/qpid/agent
* qpid/cpp/\{include,src\}/qpid/console
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
