[jira] Commented: (QPID-2473) current libraries: new options needed to link with
[ https://issues.apache.org/jira/browse/QPID-2473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12851784#action_12851784 ] Jan Sarenik commented on QPID-2473: --- Building with CMake does not help either... [ 79%] Built target ssl [ 79%] Built target sslconnector [ 80%] Built target watchdog [ 80%] Building CXX object src/CMakeFiles/xml.dir/qpid/xml/XmlExchange.o /var/tmp/jasan/qpid-20100330/cpp/src/qpid/xml/XmlExchange.cpp: In member function 'bool qpid::broker::XmlExchange::matches(boost::shared_ptrXQQuery, qpid::broker::Deliverable, const qpid::framing::FieldTable*, bool)': /var/tmp/jasan/qpid-20100330/cpp/src/qpid/xml/XmlExchange.cpp:192: error: 'class ResultImpl' has no member named 'getEffectiveBooleanValue' make[2]: *** [src/CMakeFiles/xml.dir/qpid/xml/XmlExchange.o] Error 1 make[1]: *** [src/CMakeFiles/xml.dir/all] Error 2 make: *** [all] Error 2 cmake-2.8.1-0.2.rc5.fc14.x86_64 xqilla-devel-2.2.3-7.fc14.x86_64 xerces-c-devel-3.0.1-16.fc13.x86_64 current libraries: new options needed to link with -- Key: QPID-2473 URL: https://issues.apache.org/jira/browse/QPID-2473 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.7 Environment: Linux slanina.virtual 2.6.34-0.16.rc2.git0.fc14.x86_64 #1 SMP Tue Mar 23 02:02:52 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux fedora-release-14-0.4.noarch (Rawhide x86_64) glibc-2.11.90-16.x86_64 gcc-4.4.3-13.fc14.x86_64 gcc-c++-4.4.3-13.fc14.x86_64 boost-1.41.0-7.fc13.x86_64 Reporter: Jan Sarenik Assignee: Gordon Sim Attachments: qpid-rawhide.diff The little attached patch is vital to make current trunk (r928701) compile on Fedora Rawhide with Boost 1.41.0. The other line adds libpthread linking option. It works but you may want to add it elsewhere if you choose to do so. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2418) Existing durable subscription with selector is not unsubscribed during change to new subscription
[ https://issues.apache.org/jira/browse/QPID-2418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2418: - Attachment: (was: 0001-QPID-2418-trunk.patch) Existing durable subscription with selector is not unsubscribed during change to new subscription -- Key: QPID-2418 URL: https://issues.apache.org/jira/browse/QPID-2418 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: M4, 0.5, 0.6 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.7 AMQSession.createDurableSubscriber(topic, name, messageSelector, noLocal) does not unsubscribe existing durable subscriptions. Whilst it does check for existing durable subscriptions in use by the client with the same name, it instead simply closes the subscriptions then creates a new one. As a result of not unsubscribing, the queue backing the subscription is not deleted before being used by the updated subscription as it should be (and as happens in the 0_8 and 0_10 subclasses when using durable subscriptions without selectors). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2418) Existing durable subscription with selector is not unsubscribed during change to new subscription
[ https://issues.apache.org/jira/browse/QPID-2418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2418: - Attachment: 0001-QPID-2418-trunk.patch 0001-QPID-2418-branch.patch Existing durable subscription with selector is not unsubscribed during change to new subscription -- Key: QPID-2418 URL: https://issues.apache.org/jira/browse/QPID-2418 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: M4, 0.5, 0.6 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.7 Attachments: 0001-QPID-2418-branch.patch, 0001-QPID-2418-trunk.patch AMQSession.createDurableSubscriber(topic, name, messageSelector, noLocal) does not unsubscribe existing durable subscriptions. Whilst it does check for existing durable subscriptions in use by the client with the same name, it instead simply closes the subscriptions then creates a new one. As a result of not unsubscribing, the queue backing the subscription is not deleted before being used by the updated subscription as it should be (and as happens in the 0_8 and 0_10 subclasses when using durable subscriptions without selectors). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2360) declaring virtualhost level firewall configuration in virtualhosts.xml leads to NPE on startup
[ https://issues.apache.org/jira/browse/QPID-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12851798#action_12851798 ] Robbie Gemmell commented on QPID-2360: -- Patches were commited in revisions 929136 and 929138. The commit log statement was incorrect at the time, but has since been updated with the correct issue numbers. declaring virtualhost level firewall configuration in virtualhosts.xml leads to NPE on startup -- Key: QPID-2360 URL: https://issues.apache.org/jira/browse/QPID-2360 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.6 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.7 Attachments: 0001-QPID-2630-QPID-2631-branch.patch, 0001-QPID-2630-QPID-2631-trunk.patch Declaring virtualhost level firewall configuration in virtualhosts.xml leads to NPE on startup. After moving the same configuration into config.xml the broker then loads ok and the configuration works as expected. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2477) std::cout in agent not used anymore
[ https://issues.apache.org/jira/browse/QPID-2477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Sarenik updated QPID-2477: -- Attachment: qpid-agent-cout.diff std::cout in agent not used anymore --- Key: QPID-2477 URL: https://issues.apache.org/jira/browse/QPID-2477 Project: Qpid Issue Type: Improvement Components: C++ Broker Affects Versions: 0.7 Environment: Fedora Rawhide, Linux 2.6.34 x86_64, ... not important here Reporter: Jan Sarenik Priority: Trivial Fix For: 0.7 Attachments: qpid-agent-cout.diff See attached patch. It removes the obsolete line. (All cout calls were removed from C++ agent in r727265) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2477) std::cout in agent not used anymore
std::cout in agent not used anymore --- Key: QPID-2477 URL: https://issues.apache.org/jira/browse/QPID-2477 Project: Qpid Issue Type: Improvement Components: C++ Broker Affects Versions: 0.7 Environment: Fedora Rawhide, Linux 2.6.34 x86_64, ... not important here Reporter: Jan Sarenik Priority: Trivial Fix For: 0.7 Attachments: qpid-agent-cout.diff See attached patch. It removes the obsolete line. (All cout calls were removed from C++ agent in r727265) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2477) std::cout in agent not used anymore
[ https://issues.apache.org/jira/browse/QPID-2477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Sarenik updated QPID-2477: -- Description: See attached one-liner. It removes the obsolete line. (All cout calls were removed from C++ agent in r727265) was: See attached patch. It removes the obsolete line. (All cout calls were removed from C++ agent in r727265) std::cout in agent not used anymore --- Key: QPID-2477 URL: https://issues.apache.org/jira/browse/QPID-2477 Project: Qpid Issue Type: Improvement Components: C++ Broker Affects Versions: 0.7 Environment: Fedora Rawhide, Linux 2.6.34 x86_64, ... not important here Reporter: Jan Sarenik Priority: Trivial Fix For: 0.7 Attachments: qpid-agent-cout.diff See attached one-liner. It removes the obsolete line. (All cout calls were removed from C++ agent in r727265) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2418) Existing durable subscription with selector is not unsubscribed during change to new subscription
[ https://issues.apache.org/jira/browse/QPID-2418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2418: - Attachment: (was: 0001-QPID-2418-branch.patch) Existing durable subscription with selector is not unsubscribed during change to new subscription -- Key: QPID-2418 URL: https://issues.apache.org/jira/browse/QPID-2418 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: M4, 0.5, 0.6 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.7 Attachments: 0001-QPID-2418-trunk.patch AMQSession.createDurableSubscriber(topic, name, messageSelector, noLocal) does not unsubscribe existing durable subscriptions. Whilst it does check for existing durable subscriptions in use by the client with the same name, it instead simply closes the subscriptions then creates a new one. As a result of not unsubscribing, the queue backing the subscription is not deleted before being used by the updated subscription as it should be (and as happens in the 0_8 and 0_10 subclasses when using durable subscriptions without selectors). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2418) Existing durable subscription with selector is not unsubscribed during change to new subscription
[ https://issues.apache.org/jira/browse/QPID-2418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2418: - Attachment: 0001-QPID-2418-trunk.patch 0001-QPID-2418-branch.patch Existing durable subscription with selector is not unsubscribed during change to new subscription -- Key: QPID-2418 URL: https://issues.apache.org/jira/browse/QPID-2418 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: M4, 0.5, 0.6 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.7 Attachments: 0001-QPID-2418-branch.patch, 0001-QPID-2418-trunk.patch AMQSession.createDurableSubscriber(topic, name, messageSelector, noLocal) does not unsubscribe existing durable subscriptions. Whilst it does check for existing durable subscriptions in use by the client with the same name, it instead simply closes the subscriptions then creates a new one. As a result of not unsubscribing, the queue backing the subscription is not deleted before being used by the updated subscription as it should be (and as happens in the 0_8 and 0_10 subclasses when using durable subscriptions without selectors). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Many Mb of doc related tools checked in
We could move back to the earlier tool chain (ant, Saxon, Xerces, DocBook DTDs, DocBook stylesheets. Instead of checking these things into subdirectories, I could put them in a zip file in my people.apache.org account, and create an ant task that retrieves them and unzips them into the right subdirectories. For people like Rafi who do not want multiple copies on their system, I could write a shell script that creates symbolic links to the standard installed locations. People can modify this as needed if they have these things installed elsewhere. That's the best I've thought of so far. Thoughts? Jonathan - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Many Mb of doc related tools checked in
On 03/31/2010 12:18 PM, Emmanuel Bourg wrote: That's still better than installing the tool chain manually, but that sounds like a lot of troubles for something that is already done with a short Maven file. I'm more than happy to do what the group wants if (1) the group can all want the same thing, and (2) it's reasonably simple. I think Maven is out, because people have been pretty loud about not wanting Yet Another Build System. Jonathan P.S. Did you run into problems trying to build on Windows using the tools mentioned in README.txt? - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Performance measurement clients using the new API.
I think we can extend qpid_send and qpid_recv to do most of the things that perftest and latencytest do. Interested in any ideas on the topic. Here's what I propose: Additional qpid_send options: --report=Y/N: report sender throughput on exit. --report-interval=SECS: print throughput report every N seconds. --timestamp=Y/N: timestamp each message. --rate=MSGS/SEC: send at this rate, 0 means fast as possible. --padding=BYTES: add this much padding to messages. --time-limit=SECS: stop after this time, 0 means no limit. --max-noreply=N: don't send more than N messages without receiving a reply. Creates a reply queue and sets reply_to on every N/2 messages. Additional qpid_recv options: --report=Y/N: report latency and throughput statistics on exit. Latency is only calculated for messages with a timestamp. --report-interval=SECS: print latency and throughput statistics every N seconds. New qpid_recv behavior: if reply-to is set, echo the message to that address. The --max-noreply=N option is a simple form of end-to-end throughput. The sender sets reply-to on every N/2 messages. It won't send more than N messages beyond the last message that was replied to. The receiver replies whenever reply-to is set. Multiple instances of sender receiver can be mixed and matched however you want, to measure e.g. shared queue, pub-sub etc. scenarios. I'm deliberately avoiding the do-everything swiss army knife approach of perftest, that results in an overly complex test that is not as flexible as the separate sender/receiver approach. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Size of the Java client
would expect a message queue client to be not bigger than ~500KB (dependencies included and fully compressed with pack200+lzma) 500KB would be nice. Some of my science experiments target Java-based platforms with 1MB of Flash and 1MB of RAM. For now I open sockets to a server, and the server in turn does any queue manaement things as needed. http://www.maxim-ic.com/products/microcontrollers/tini/ Cheers, -JK - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Many Mb of doc related tools checked in
Jonathan Robie a écrit : I think Maven is out, because people have been pretty loud about not wanting Yet Another Build System. In this case Maven isn't used as a build system, it's just a convenient tool to build the documentation on any platform. P.S. Did you run into problems trying to build on Windows using the tools mentioned in README.txt? Certainly, yum doesn't work on Windows ;) Installing the tool chain manually is really a pain, I didn't try since I knew a simpler alternative. I don't want to disrupt your habits, keep the make file as the main way to build the documentation. I would just suggest adding a simple alternative for the developers that aren't using the reference system. Emmanuel Bourg - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Many Mb of doc related tools checked in
On Wed, Mar 31, 2010 at 12:53 PM, Emmanuel Bourg ebo...@apache.org wrote: Jonathan Robie a écrit : I think Maven is out, because people have been pretty loud about not wanting Yet Another Build System. In this case Maven isn't used as a build system, it's just a convenient tool to build the documentation on any platform. I am sorry sir, but Maven is a big no due to the well documented reasons. You are paying a big price for that convenience :). P.S. Did you run into problems trying to build on Windows using the tools mentioned in README.txt? Certainly, yum doesn't work on Windows ;) Installing the tool chain manually is really a pain, I didn't try since I knew a simpler alternative. Even if you download it manually it's a one time job. I don't know why folks are so worried about it. The price you pay for the simple alternative is way too much :). I don't want to disrupt your habits, keep the make file as the main way to build the documentation. I would just suggest adding a simple alternative for the developers that aren't using the reference system. Emmanuel Bourg - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-2477) std::cout in agent not used anymore
[ https://issues.apache.org/jira/browse/QPID-2477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved QPID-2477. -- Resolution: Fixed std::cout in agent not used anymore --- Key: QPID-2477 URL: https://issues.apache.org/jira/browse/QPID-2477 Project: Qpid Issue Type: Improvement Components: C++ Broker Affects Versions: 0.7 Environment: Fedora Rawhide, Linux 2.6.34 x86_64, ... not important here Reporter: Jan Sarenik Priority: Trivial Fix For: 0.7 Attachments: qpid-agent-cout.diff See attached one-liner. It removes the obsolete line. (All cout calls were removed from C++ agent in r727265) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Many Mb of doc related tools checked in
Rajith Attapattu a écrit : I am sorry sir, but Maven is a big no due to the well documented reasons. You are paying a big price for that convenience :). I understand you had some troubles in the past with Maven, and considering the complexity of the Qpid project I'm not surprised. But for the specific purpose of building the documentation I don't think the well documented reasons apply. Even if you download it manually it's a one time job. I don't know why folks are so worried about it. Because it's a waste of time for anyone interested in building the documentation. Because one has to reinstall most of the tool chain on every checkout of the project (the Ant build assumes the stylesheets are copied in qpid/doc/book/docbook-xsl, and not outside the project tree). You do it once on your desktop computer, then once on your laptop, and then every time you checkout a different branch. That's definitely not a one time job. Emmanuel Bourg - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2418) Existing durable subscription with selector is not unsubscribed during change to new subscription
[ https://issues.apache.org/jira/browse/QPID-2418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12851997#action_12851997 ] Rajith Attapattu commented on QPID-2418: When investigating the test failure for testResubscribeWithChangedSelector in the DurableSubscriptionTest, I was a bit shocked to see the amount of code duplication. This may have been due to a merge, but we definitely need to fix this. So thx for taking care of this. I haven't had chance to have a closer look at the patches, but please make sure tests pass against both the C++ and Java Broker before committing it. Also the change made in rev 929095 to the DurableSubscriptionTest.java (method testResubscribeWithChangedSelector) is somehow passing for the Java broker. Bcos we have the bug mentioned in this bug, it should be failing in both brokers. I am not so happy about checking in the change to the test case before a fix is committed as this has broken our automated builds. Perhaps the Java broker is creating a new queue as the arguments list is different (the selector being different) ? Isn't that a bug? Perhaps worthwhile investigating this. Existing durable subscription with selector is not unsubscribed during change to new subscription -- Key: QPID-2418 URL: https://issues.apache.org/jira/browse/QPID-2418 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: M4, 0.5, 0.6 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.7 Attachments: 0001-QPID-2418-branch.patch, 0001-QPID-2418-trunk.patch AMQSession.createDurableSubscriber(topic, name, messageSelector, noLocal) does not unsubscribe existing durable subscriptions. Whilst it does check for existing durable subscriptions in use by the client with the same name, it instead simply closes the subscriptions then creates a new one. As a result of not unsubscribing, the queue backing the subscription is not deleted before being used by the updated subscription as it should be (and as happens in the 0_8 and 0_10 subclasses when using durable subscriptions without selectors). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Mina version
Could someone enlighten me about the Mina version currently used in Qpid please? I searched through the messages of the list back to 2006 and found this: http://mail-archives.apache.org/mod_mbox/qpid-dev/200612.mbox/%3cc5e632550612010029j3c0beec6p4eeff0aab1d36...@mail.gmail.com%3e That is, Qpid uses a snapshot version build from the revision 463149 at http://svn.apache.org/repos/asf/mina/trunk. However I also found mention of performance patches that were necessary for Qpid. Are they also included in the revision above or were they applied separately? Thank you, Emmanuel Bourg - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Performance measurement clients using the new API.
Gordon Sim wrote: On 03/31/2010 05:41 PM, Alan Conway wrote: I think we can extend qpid_send and qpid_recv to do most of the things that perftest and latencytest do. Interested in any ideas on the topic. I like the approach. +1 Here's what I propose: Additional qpid_send options: --report=Y/N: report sender throughput on exit. --report-interval=SECS: print throughput report every N seconds. FYI qpid-bench does this based on # of messages as opposed to time (not sure which is preferred or if both make sense in some scenarios). --timestamp=Y/N: timestamp each message. --rate=MSGS/SEC: send at this rate, 0 means fast as possible. --padding=BYTES: add this much padding to messages. --time-limit=SECS: stop after this time, 0 means no limit. --max-noreply=N: don't send more than N messages without receiving a reply. Creates a reply queue and sets reply_to on every N/2 messages. In addition you'd need to configure things like sender/receiver capacity, sync/async, etc. qpid_send currently reads in message content from std::in. This can be very useful for ad-hoc tests or scripting different types of test. However for performance you would most likely want to avoid any extra overhead and have the message content generated by the tool itself. Additional qpid_recv options: --report=Y/N: report latency and throughput statistics on exit. Latency is only calculated for messages with a timestamp. --report-interval=SECS: print latency and throughput statistics every N seconds. New qpid_recv behavior: if reply-to is set, echo the message to that address. I could see two different types of useful behaviour here. One as above, where you echo the message. Another would simply be to send an empty message correlated by correlation-id. E.g. for the case where the original message is very large and you only wish the response to indicate that it was received (could have received message sie in the response message in some way). Of course keeping it simple to begin with is also fine! If we want the flexibility I would suggest putting some sort of opcode in the original message that would instruct the receiver how to respond, e.g. echo the original message, send an empty (but correlated) message, or even send a message with the receiver's current stats in it. qpid_recv also prints out each message to std::out and again this would need to be optional to avoid impacting perf numbers. The python drain example has a nice feature where you can specify what aspect of each message gets printed. Adding that to qpid_recv would be valuable. The --max-noreply=N option is a simple form of end-to-end throughput. The sender sets reply-to on every N/2 messages. It won't send more than N messages beyond the last message that was replied to. The receiver replies whenever reply-to is set. Multiple instances of sender receiver can be mixed and matched however you want, to measure e.g. shared queue, pub-sub etc. scenarios. I'm deliberately avoiding the do-everything swiss army knife approach of perftest, that results in an overly complex test that is not as flexible as the separate sender/receiver approach. One thing that would be useful is to have multiple sessions per connection for send/recv. This would be useful even for performance testing, though it does complicate the reporting a little. Overall I'm not sure we should try to cram too much into qpid-send and qpid-recv. I think it might make sense to have two sets of utilities with the difference being based on whether the utilities themselves generate the messages, or whether they're simply used to send/recv messages generated outside the utilities. I think the use cases around these two scenarios are fairly different. The things that generate/consume their own content are more oriented towards diagnostics/testing/benchmarking, and I would expect to have options around frequency, size, type of content, etc, whereas the things that send/recv existing content would have more options around reading in messages from various formats, writing them out, etc. I propose thinking in terms of qpid-send/qpid-recv which are basically command line versions of the API used to send/recv message content generated outside the utility (that content could come by file, command-line args, stdin, etc), and then qpid-source/qpid-sink which are used as artificial sources/sinks for messages and more oriented towards testing/diagnostics/performance. --Rafael - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2418) Existing durable subscription with selector is not unsubscribed during change to new subscription
[ https://issues.apache.org/jira/browse/QPID-2418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12852032#action_12852032 ] Robbie Gemmell commented on QPID-2418: -- The changes made to DurableSubscriptionTest were not intended to yet expose this bug any more than it was, and were deliberately kept short so that they wouldnt (the comment is innacurate youll note, as it isnt doing what it was originally and I forgot to update that). The new test added in DurableSubscriberTest that absolutely would expose it was excluded until it is fixed so that automated builds wouldnt be been broken. What I didnt do was run the test using the C++ broker as I didnt think I was changing anything of any particular note, but I failed to consider that it could behave slightly differently due to use of client side selectors rather than the server side selectors used by the Java broker. The broker doenst create a new queue, but it does change the filters used to select messages meaning that messges never get onto the queue which will on the C++ broker, which I imagine is where the test now fails. I'll take that into account when updating it. Existing durable subscription with selector is not unsubscribed during change to new subscription -- Key: QPID-2418 URL: https://issues.apache.org/jira/browse/QPID-2418 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: M4, 0.5, 0.6 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.7 Attachments: 0001-QPID-2418-branch.patch, 0001-QPID-2418-trunk.patch AMQSession.createDurableSubscriber(topic, name, messageSelector, noLocal) does not unsubscribe existing durable subscriptions. Whilst it does check for existing durable subscriptions in use by the client with the same name, it instead simply closes the subscriptions then creates a new one. As a result of not unsubscribing, the queue backing the subscription is not deleted before being used by the updated subscription as it should be (and as happens in the 0_8 and 0_10 subclasses when using durable subscriptions without selectors). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: svn commit: r929095 - in /qpid/trunk/qpid/java: systests/src/main/java/org/apache/qpid/test/unit/ct/ systests/src/main/java/org/apache/qpid/test/unit/topic/ test-profiles/
The changes made to DurableSubscriptionTest were not intended to yet expose
this bug any more than it was, and were deliberately kept short so that they
wouldnt (the comment is innacurate youll note, as it isnt doing what it was
originally and I forgot to update that). The new test added in
DurableSubscriberTest that absolutely would expose it was excluded until it
is fixed so that automated builds wouldnt be been broken.
What I didnt do was run the test using the C++ broker as I didnt think I was
changing anything of any particular note, but I failed to consider that it
could behave slightly differently due to use of client side selectors rather
than the server side selectors used by the Java broker. The broker doesnt
create a new queue, but it does change the filters used to select messages
meaning that messages never get onto the queue which will on the C++ broker,
which I imagine is where the test now fails. I'll take that into account
when updating it.
Robbie
-Original Message-
From: Rajith Attapattu [mailto:rajit...@gmail.com]
Sent: 31 March 2010 19:20
To: dev@qpid.apache.org; robbie.gemm...@gmail.com
Subject: Re: svn commit: r929095 - in /qpid/trunk/qpid/java:
systests/src/main/java/org/apache/qpid/test/unit/ct/
systests/src/main/java/org/apache/qpid/test/unit/topic/ test-profiles/
Robbie,
The change to the test case is causing the test to fail when run
against the c++ (which should be expected as we have a bug in the Java
client).
However it's passing against the Java broker, so perhaps better to
investigate this.
I suspect the broker is creating a new queue bcos the args list is
different (the selector being different)?
Also I think we shouldn't change any tests before a fix is made.
Currently our automated builds are failing due to this.
I hope andrew gets a chance to check in his fix soon.
Regards,
Rajith
On Tue, Mar 30, 2010 at 7:50 AM, rob...@apache.org wrote:
Author: robbie
Date: Tue Mar 30 11:50:18 2010
New Revision: 929095
URL: http://svn.apache.org/viewvc?rev=929095view=rev
Log:
QPID-2417 , QPID-2418 , QPID-2449 : expand topic testing,
specifically around the change and unsubscription of durable
subscriptions
Modified:
qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/unit/
ct/DurableSubscriberTest.java
qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/unit/
topic/DurableSubscriptionTest.java
qpid/trunk/qpid/java/test-profiles/Excludes
qpid/trunk/qpid/java/test-profiles/JavaExcludes
Modified:
qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/unit/c
t/DurableSubscriberTest.java
URL:
http://svn.apache.org/viewvc/qpid/trunk/qpid/java/systests/src/main/jav
a/org/apache/qpid/test/unit/ct/DurableSubscriberTest.java?rev=929095r1
=929094r2=929095view=diff
===
===
---
qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/unit/c
t/DurableSubscriberTest.java (original)
+++
qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/unit/c
t/DurableSubscriberTest.java Tue Mar 30 11:50:18 2010
@@ -19,6 +19,10 @@ package org.apache.qpid.test.unit.ct;
import javax.jms.*;
+import org.apache.qpid.client.AMQConnection;
+import org.apache.qpid.client.AMQQueue;
+import org.apache.qpid.client.AMQSession;
+import org.apache.qpid.client.AMQTopic;
import org.apache.qpid.test.utils.QpidTestCase;
/**
@@ -163,5 +167,301 @@ public class DurableSubscriberTest exten
durConnection2.close();
}
}
+
+ /**
+ * create and register a durable subscriber without a message
selector and then unsubscribe it
+ * create and register a durable subscriber with a message
selector and then close it
+ * restart the broker
+ * send matching and non matching messages
+ * recreate and register the durable subscriber with a message
selector
+ * verify only the matching messages are received
+ */
+ public void testDurSubChangedToHaveSelectorThenRestart() throws
Exception
+ {
+ if (! isBrokerStorePersistent())
+ {
+ _logger.warn(Test skipped due to requirement of a
persistent store);
+ return;
+ }
+
+ final String SUB_NAME=getTestQueueName();
+
+ TopicConnectionFactory factory = getConnectionFactory();
+ Topic topic = (Topic)
getInitialContext().lookup(_topicName);
+
+ //create and register a durable subscriber then unsubscribe
it
+ TopicConnection durConnection =
factory.createTopicConnection(guest, guest);
+ TopicSession durSession =
durConnection.createTopicSession(false, Session.AUTO_ACKNOWLEDGE);
+ TopicSubscriber durSub1 =
durSession.createDurableSubscriber(topic, SUB_NAME);
+ durConnection.start();
+ durSub1.close();
+
Re: Performance measurement clients using the new API.
On Wed, 31 Mar 2010, Rafael Schloming wrote: Overall I'm not sure we should try to cram too much into qpid-send and qpid-recv. I think it might make sense to have two sets of utilities with the difference being based on whether the utilities themselves generate the messages, or whether they're simply used to send/recv messages generated outside the utilities. I think the use cases around these two scenarios are fairly different. The things that generate/consume their own content are more oriented towards diagnostics/testing/benchmarking, and I would expect to have options around frequency, size, type of content, etc, whereas the things that send/recv existing content would have more options around reading in messages from various formats, writing them out, etc. I propose thinking in terms of qpid-send/qpid-recv which are basically command line versions of the API used to send/recv message content generated outside the utility (that content could come by file, command-line args, stdin, etc), and then qpid-source/qpid-sink which are used as artificial sources/sinks for messages and more oriented towards testing/diagnostics/performance. (Watch out! Naming talk.) Generally speaking, names in user-facing tools should identity match their equivalents in other contexts (the API modulo stemming, language in documentation, etc). Variation is useful to the user when it stands for a difference, and it's detrimental when it doesn't. Since recv doesn't appear in the API or elsewhere in qpid messaging, it shouldn't appear in the tool's name either. recv may seem nice because it's shorter, but it's one more variant for the user to remember. So, I'd vote for qpid-receive instead. Justin - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: svn commit: r926829 - /qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client/message/JMSDestinationTest.java
This new test fails on all the Java test profiles other than java.0.10. Is it
ok to exclude it from these?
Regards,
Robbie
-Original Message-
From: raj...@apache.org [mailto:raj...@apache.org]
Sent: 23 March 2010 22:48
To: comm...@qpid.apache.org
Subject: svn commit: r926829 -
/qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/clien
t/message/JMSDestinationTest.java
Author: rajith
Date: Tue Mar 23 22:48:23 2010
New Revision: 926829
URL: http://svn.apache.org/viewvc?rev=926829view=rev
Log:
Added test case for QPID-2242 using a custom exchange to verify the
fix.
Modified:
qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client
/message/JMSDestinationTest.java
Modified:
qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client
/message/JMSDestinationTest.java
URL:
http://svn.apache.org/viewvc/qpid/trunk/qpid/java/systests/src/main/jav
a/org/apache/qpid/test/client/message/JMSDestinationTest.java?rev=92682
9r1=926828r2=926829view=diff
===
===
---
qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client
/message/JMSDestinationTest.java (original)
+++
qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client
/message/JMSDestinationTest.java Tue Mar 23 22:48:23 2010
@@ -21,9 +21,11 @@
package org.apache.qpid.test.client.message;
import org.apache.qpid.configuration.ClientProperties;
+import org.apache.qpid.client.AMQAnyDestination;
import org.apache.qpid.client.AMQDestination;
import org.apache.qpid.client.AMQTopic;
import org.apache.qpid.client.CustomJMSXProperty;
+import org.apache.qpid.framing.AMQShortString;
import org.apache.qpid.management.common.mbeans.ManagedQueue;
import org.apache.qpid.test.utils.JMXTestUtils;
import org.apache.qpid.test.utils.QpidTestCase;
@@ -327,4 +329,45 @@ public class JMSDestinationTest extends
}
+/**
+ * Send a message to a custom exchange and then verify
+ * the message received has the proper destination set
+ *
+ * @throws Exception
+ */
+public void testGetDestinationWithCustomExchange() throws
Exception
+{
+
+AMQDestination dest = new AMQAnyDestination(new
AMQShortString(my-exchange),
+new
AMQShortString(direct),
+new
AMQShortString(test),
+false,
+false,
+new
AMQShortString(test),
+false,
+new
AMQShortString[]{new AMQShortString(test)});
+
+// to force the creation of my-exchange.
+sendMessage(_session, dest, 1);
+
+MessageProducer prod = _session.createProducer(dest);
+
+MessageConsumer consumer = _session.createConsumer(dest);
+
+_connection.start();
+
+sendMessage(_session, dest, 1);
+
+Message message = consumer.receive(1);
+
+assertNotNull(Message should not be null, message);
+
+Destination destination = message.getJMSDestination();
+
+assertNotNull(JMSDestination should not be null,
destination);
+
+assertEquals(Incorrect Destination name, my-exchange,
dest.getExchangeName().asString());
+assertEquals(Incorrect Destination type, direct,
dest.getExchangeClass().asString());
+assertEquals(Incorrect Routing Key, test,
dest.getRoutingKey().asString());
+}
}
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:commits-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-2418) Existing durable subscription with selector is not unsubscribed during change to new subscription
[ https://issues.apache.org/jira/browse/QPID-2418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12852046#action_12852046 ] Rajith Attapattu commented on QPID-2418: Interesting, the queue declare with the new selector merely updates the the selector on the queue? The AMQP spec doesn't really define the behaviour if a queue declare is sent with the same name but different args (in this case the selector). So I wouldn't argue that the Java broker is wrong. The c++ client merely ignores the queue declare. IMO I think both brokers are wrong as this can lead to subtle errors that can go undetected - but thats separate topic all together. So on the C++ side, the queue is not deleted due to the java client bug. So the message is there and gets sent to the client who now has a new selector (with 0-10 client side selectors) which matches and the message is delivered. Anyways once we fix the Java client to issue a queue this should be taken care of. Always a good idea to run the default java and c++ profiles before an update. Existing durable subscription with selector is not unsubscribed during change to new subscription -- Key: QPID-2418 URL: https://issues.apache.org/jira/browse/QPID-2418 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: M4, 0.5, 0.6 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.7 Attachments: 0001-QPID-2418-branch.patch, 0001-QPID-2418-trunk.patch AMQSession.createDurableSubscriber(topic, name, messageSelector, noLocal) does not unsubscribe existing durable subscriptions. Whilst it does check for existing durable subscriptions in use by the client with the same name, it instead simply closes the subscriptions then creates a new one. As a result of not unsubscribing, the queue backing the subscription is not deleted before being used by the updated subscription as it should be (and as happens in the 0_8 and 0_10 subclasses when using durable subscriptions without selectors). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: svn commit: r926829 - /qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client/message/JMSDestinationTest.java
We could temporarily exclude until the issue is fixed.
If you are going to check in a fix soon, I'd say don't bother.
Rajith
On Wed, Mar 31, 2010 at 2:54 PM, Robbie Gemmell
robbie.gemm...@gmail.com wrote:
This new test fails on all the Java test profiles other than java.0.10. Is it
ok to exclude it from these?
Regards,
Robbie
-Original Message-
From: raj...@apache.org [mailto:raj...@apache.org]
Sent: 23 March 2010 22:48
To: comm...@qpid.apache.org
Subject: svn commit: r926829 -
/qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/clien
t/message/JMSDestinationTest.java
Author: rajith
Date: Tue Mar 23 22:48:23 2010
New Revision: 926829
URL: http://svn.apache.org/viewvc?rev=926829view=rev
Log:
Added test case for QPID-2242 using a custom exchange to verify the
fix.
Modified:
qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client
/message/JMSDestinationTest.java
Modified:
qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client
/message/JMSDestinationTest.java
URL:
http://svn.apache.org/viewvc/qpid/trunk/qpid/java/systests/src/main/jav
a/org/apache/qpid/test/client/message/JMSDestinationTest.java?rev=92682
9r1=926828r2=926829view=diff
===
===
---
qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client
/message/JMSDestinationTest.java (original)
+++
qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client
/message/JMSDestinationTest.java Tue Mar 23 22:48:23 2010
@@ -21,9 +21,11 @@
package org.apache.qpid.test.client.message;
import org.apache.qpid.configuration.ClientProperties;
+import org.apache.qpid.client.AMQAnyDestination;
import org.apache.qpid.client.AMQDestination;
import org.apache.qpid.client.AMQTopic;
import org.apache.qpid.client.CustomJMSXProperty;
+import org.apache.qpid.framing.AMQShortString;
import org.apache.qpid.management.common.mbeans.ManagedQueue;
import org.apache.qpid.test.utils.JMXTestUtils;
import org.apache.qpid.test.utils.QpidTestCase;
@@ -327,4 +329,45 @@ public class JMSDestinationTest extends
}
+ /**
+ * Send a message to a custom exchange and then verify
+ * the message received has the proper destination set
+ *
+ * @throws Exception
+ */
+ public void testGetDestinationWithCustomExchange() throws
Exception
+ {
+
+ AMQDestination dest = new AMQAnyDestination(new
AMQShortString(my-exchange),
+ new
AMQShortString(direct),
+ new
AMQShortString(test),
+ false,
+ false,
+ new
AMQShortString(test),
+ false,
+ new
AMQShortString[]{new AMQShortString(test)});
+
+ // to force the creation of my-exchange.
+ sendMessage(_session, dest, 1);
+
+ MessageProducer prod = _session.createProducer(dest);
+
+ MessageConsumer consumer = _session.createConsumer(dest);
+
+ _connection.start();
+
+ sendMessage(_session, dest, 1);
+
+ Message message = consumer.receive(1);
+
+ assertNotNull(Message should not be null, message);
+
+ Destination destination = message.getJMSDestination();
+
+ assertNotNull(JMSDestination should not be null,
destination);
+
+ assertEquals(Incorrect Destination name, my-exchange,
dest.getExchangeName().asString());
+ assertEquals(Incorrect Destination type, direct,
dest.getExchangeClass().asString());
+ assertEquals(Incorrect Routing Key, test,
dest.getRoutingKey().asString());
+ }
}
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:commits-subscr...@qpid.apache.org
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: svn commit: r926829 - /qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client/message/JMSDestinationTest.java
I don't have any current plans to look at it, so ill exclude it tomorrow
(can't be bothered firing up the dev env just now, enough of this computer
lark for tonight... time for Lost :P)
Robbie
-Original Message-
From: Rajith Attapattu [mailto:rajit...@gmail.com]
Sent: 31 March 2010 19:57
To: dev@qpid.apache.org
Subject: Re: svn commit: r926829 -
/qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/clien
t/message/JMSDestinationTest.java
We could temporarily exclude until the issue is fixed.
If you are going to check in a fix soon, I'd say don't bother.
Rajith
On Wed, Mar 31, 2010 at 2:54 PM, Robbie Gemmell
robbie.gemm...@gmail.com wrote:
This new test fails on all the Java test profiles other than
java.0.10. Is it ok to exclude it from these?
Regards,
Robbie
-Original Message-
From: raj...@apache.org [mailto:raj...@apache.org]
Sent: 23 March 2010 22:48
To: comm...@qpid.apache.org
Subject: svn commit: r926829 -
/qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/clien
t/message/JMSDestinationTest.java
Author: rajith
Date: Tue Mar 23 22:48:23 2010
New Revision: 926829
URL: http://svn.apache.org/viewvc?rev=926829view=rev
Log:
Added test case for QPID-2242 using a custom exchange to verify the
fix.
Modified:
qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client
/message/JMSDestinationTest.java
Modified:
qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client
/message/JMSDestinationTest.java
URL:
http://svn.apache.org/viewvc/qpid/trunk/qpid/java/systests/src/main/jav
a/org/apache/qpid/test/client/message/JMSDestinationTest.java?rev=92682
9r1=926828r2=926829view=diff
===
===
---
qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client
/message/JMSDestinationTest.java (original)
+++
qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client
/message/JMSDestinationTest.java Tue Mar 23 22:48:23 2010
@@ -21,9 +21,11 @@
package org.apache.qpid.test.client.message;
import org.apache.qpid.configuration.ClientProperties;
+import org.apache.qpid.client.AMQAnyDestination;
import org.apache.qpid.client.AMQDestination;
import org.apache.qpid.client.AMQTopic;
import org.apache.qpid.client.CustomJMSXProperty;
+import org.apache.qpid.framing.AMQShortString;
import org.apache.qpid.management.common.mbeans.ManagedQueue;
import org.apache.qpid.test.utils.JMXTestUtils;
import org.apache.qpid.test.utils.QpidTestCase;
@@ -327,4 +329,45 @@ public class JMSDestinationTest extends
}
+ /**
+ * Send a message to a custom exchange and then verify
+ * the message received has the proper destination set
+ *
+ * @throws Exception
+ */
+ public void testGetDestinationWithCustomExchange() throws
Exception
+ {
+
+ AMQDestination dest = new AMQAnyDestination(new
AMQShortString(my-exchange),
+ new
AMQShortString(direct),
+ new
AMQShortString(test),
+ false,
+ false,
+ new
AMQShortString(test),
+ false,
+ new
AMQShortString[]{new AMQShortString(test)});
+
+ // to force the creation of my-exchange.
+ sendMessage(_session, dest, 1);
+
+ MessageProducer prod = _session.createProducer(dest);
+
+ MessageConsumer consumer = _session.createConsumer(dest);
+
+ _connection.start();
+
+ sendMessage(_session, dest, 1);
+
+ Message message = consumer.receive(1);
+
+ assertNotNull(Message should not be null, message);
+
+ Destination destination = message.getJMSDestination();
+
+ assertNotNull(JMSDestination should not be null,
destination);
+
+ assertEquals(Incorrect Destination name, my-exchange,
dest.getExchangeName().asString());
+ assertEquals(Incorrect Destination type, direct,
dest.getExchangeClass().asString());
+ assertEquals(Incorrect Routing Key, test,
dest.getRoutingKey().asString());
+ }
}
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:commits-subscr...@qpid.apache.org
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
--
Re: Performance measurement clients using the new API.
On 03/31/2010 02:22 PM, Rafael Schloming wrote: Gordon Sim wrote: On 03/31/2010 05:41 PM, Alan Conway wrote: I think we can extend qpid_send and qpid_recv to do most of the things that perftest and latencytest do. Interested in any ideas on the topic. I like the approach. +1 Here's what I propose: Additional qpid_send options: --report=Y/N: report sender throughput on exit. --report-interval=SECS: print throughput report every N seconds. FYI qpid-bench does this based on # of messages as opposed to time (not sure which is preferred or if both make sense in some scenarios). --timestamp=Y/N: timestamp each message. --rate=MSGS/SEC: send at this rate, 0 means fast as possible. --padding=BYTES: add this much padding to messages. --time-limit=SECS: stop after this time, 0 means no limit. --max-noreply=N: don't send more than N messages without receiving a reply. Creates a reply queue and sets reply_to on every N/2 messages. In addition you'd need to configure things like sender/receiver capacity, sync/async, etc. Indeed, some if this is already there in qpid_send the options mentioned above are additions to whats there now. qpid_send currently reads in message content from std::in. This can be very useful for ad-hoc tests or scripting different types of test. However for performance you would most likely want to avoid any extra overhead and have the message content generated by the tool itself. Additional qpid_recv options: --report=Y/N: report latency and throughput statistics on exit. Latency is only calculated for messages with a timestamp. --report-interval=SECS: print latency and throughput statistics every N seconds. New qpid_recv behavior: if reply-to is set, echo the message to that address. I could see two different types of useful behaviour here. One as above, where you echo the message. Another would simply be to send an empty message correlated by correlation-id. E.g. for the case where the original message is very large and you only wish the response to indicate that it was received (could have received message sie in the response message in some way). Of course keeping it simple to begin with is also fine! If we want the flexibility I would suggest putting some sort of opcode in the original message that would instruct the receiver how to respond, e.g. echo the original message, send an empty (but correlated) message, or even send a message with the receiver's current stats in it. qpid_recv also prints out each message to std::out and again this would need to be optional to avoid impacting perf numbers. The python drain example has a nice feature where you can specify what aspect of each message gets printed. Adding that to qpid_recv would be valuable. The --max-noreply=N option is a simple form of end-to-end throughput. The sender sets reply-to on every N/2 messages. It won't send more than N messages beyond the last message that was replied to. The receiver replies whenever reply-to is set. Multiple instances of sender receiver can be mixed and matched however you want, to measure e.g. shared queue, pub-sub etc. scenarios. I'm deliberately avoiding the do-everything swiss army knife approach of perftest, that results in an overly complex test that is not as flexible as the separate sender/receiver approach. One thing that would be useful is to have multiple sessions per connection for send/recv. This would be useful even for performance testing, though it does complicate the reporting a little. Overall I'm not sure we should try to cram too much into qpid-send and qpid-recv. I think it might make sense to have two sets of utilities with the difference being based on whether the utilities themselves generate the messages, or whether they're simply used to send/recv messages generated outside the utilities. I think the use cases around these two scenarios are fairly different. The things that generate/consume their own content are more oriented towards diagnostics/testing/benchmarking, and I would expect to have options around frequency, size, type of content, etc, whereas the things that send/recv existing content would have more options around reading in messages from various formats, writing them out, etc. I propose thinking in terms of qpid-send/qpid-recv which are basically command line versions of the API used to send/recv message content generated outside the utility (that content could come by file, command-line args, stdin, etc), and then qpid-source/qpid-sink which are used as artificial sources/sinks for messages and more oriented towards testing/diagnostics/performance. I'm not sure I see the benefit of this distinction. I would be inclined to think of qpid-send/receive as tools that send messages generated in various ways: 2 of which being read from stdin and generated internally, we could add more as needed. --Rafael - Apache Qpid - AMQP Messaging Implementation
Re: svn commit: r926829 - /qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client/message/JMSDestinationTest.java
On Wed, Mar 31, 2010 at 7:56 PM, Rajith Attapattu rajit...@gmail.com wrote: We could temporarily exclude until the issue is fixed. If you are going to check in a fix soon, I'd say don't bother. I'm not entirely clear on what the issue with this is at this stage. Is the problem that the java broker doesn't auto-declare exchanges on first use? AFAICT ritchiem's commits in December should have resolved the problem with the header itself. In any case I think it'd be clearer if the test did an explicit exchange declare. - Aidan -- Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org A witty saying proves nothing - Voltaire - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Unresolved issues but marked 0.6
On Tue, Mar 30, 2010 at 4:28 PM, Marnie McCormack marnie.mccorm...@googlemail.com wrote: That's corect - they will have done. I've been reviewing them when time permits, but happy for other devs to review too to aid progress. Hoping we'll have more time for review in the 0.8 cycle. This is essentially inevitable with CTR. Somehow there's never enough time to get around to all the reviews, but I've never seen a patch not go in due to lack of review time with RTC. - Aidan -- Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org A witty saying proves nothing - Voltaire - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[java] transaction handling
I've recently been wrestling with transaction handling in the java broker in the context of 0-9-1 compliance. We're currently not strictly spec compliant with 0-9-1 as we will resend messages that have been rolled back. 0-9 and 0-8 are... ambiguous... on this matter, and I've been trying to retain current behaviour for them. However, it's a) a massive PITA and b) probably Not What You Want. If you're rolling back a consume it's almost certainly because you can't cope with the message. If you think b) I'd like to float the idea of 0.8 being the we are breaking backwards compatibility release so we can fix the conf file, the command line etc. Thoughts? - Aidan -- Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org A witty saying proves nothing - Voltaire - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
