Re: What to do with client-api-example-tests.py ....
Jonathan Robie wrote: On 07/21/2010 04:21 PM, Rafael Schloming wrote: I think you should forget about make and simply provide a convenient command line interface to running the tests (either via qpid-python-test or a custom script if appropriate). This can then be used to test interop outside of the source tree and can be trivially integrated by C++, Java, and/or python developers into their respective builds. This, I think, is already done in the current code. Run it like this: $ ./client-api-example-tests.py -v By default, it assumes it is being run from a Qpid source tree, and sets up paths to the test programs in their normal locations, then runs them. You don't have to configure anything if it's being run from a source tree with a broker on localhost:5672. If your broker is running at a different address, set QPID_BROKER to the address of the broker. If you're running it from outside a source tree, but have the source tree on your system, set QPID_ROOT to the source tree root. If you're running from an installed version, you have to tell the script where you installed various pieces using the following environment variables: QPID_CPP_EXAMPLES (default: qpid_root + "/cpp/examples/messaging/") QPID_PYTHON_EXAMPLES (default: qpid_root + "/python/examples/api/") PYTHONPATH (default: qpid_root+"/python:" + qpid_root+"/extras/qmf/src/py") QPID_PYTHON_TOOLS (default: qpid_root + "/tools/src/py/") QPID_HOME (default: qpid_root + "/java/build/lib/") QPID_JAVA_EXAMPLES (default: qpid_root + "/java/client/example/") I think that should be fairly easy to set up and call from various environments. I was aware of this already, but I was only able to figure it out by reading the source code. By convenient command line interface I meant something more in line with the usual unix standards, e.g. I should be able to figure out how to use the program from the -h/--help option, and it shouldn't dump logging into a random hard coded filename in the current directory and configuration should be controllable via options with environment variables for defaults only. An alternative (and possibly a better one) would be to simply integrate with the qpid-python-test runner which does much of the above for you. Either way I think that defaulting the script itself to pick stuff up from the source code layout is a problem. This code is currently sitting in a place where it will get installed and when this happens you'll end up with an installed script that by default will break horribly because all of its default expectations are wrong for the installed environment. It would make more sense to depend on standard environment variables (i.e. PATH) already being set correctly. This would allow the script to work correctly by default in an installed environment, and any integrating Makefile/build.xml/setup.py can easily set up the PATH as needed for the source tree. --Rafael - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: What to do with client-api-example-tests.py ....
On 07/21/2010 04:21 PM, Rafael Schloming wrote: I think you should forget about make and simply provide a convenient command line interface to running the tests (either via qpid-python-test or a custom script if appropriate). This can then be used to test interop outside of the source tree and can be trivially integrated by C++, Java, and/or python developers into their respective builds. This, I think, is already done in the current code. Run it like this: $ ./client-api-example-tests.py -v By default, it assumes it is being run from a Qpid source tree, and sets up paths to the test programs in their normal locations, then runs them. You don't have to configure anything if it's being run from a source tree with a broker on localhost:5672. If your broker is running at a different address, set QPID_BROKER to the address of the broker. If you're running it from outside a source tree, but have the source tree on your system, set QPID_ROOT to the source tree root. If you're running from an installed version, you have to tell the script where you installed various pieces using the following environment variables: QPID_CPP_EXAMPLES (default: qpid_root + "/cpp/examples/messaging/") QPID_PYTHON_EXAMPLES (default: qpid_root + "/python/examples/api/") PYTHONPATH (default: qpid_root+"/python:" + qpid_root+"/extras/qmf/src/py") QPID_PYTHON_TOOLS (default: qpid_root + "/tools/src/py/") QPID_HOME (default: qpid_root + "/java/build/lib/") QPID_JAVA_EXAMPLES (default: qpid_root + "/java/client/example/") I think that should be fairly easy to set up and call from various environments. Jonathan - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1909) Consumer with byte credit can get ignored if a large message "eclipses" a small one.
[
https://issues.apache.org/jira/browse/QPID-1909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway updated QPID-1909:
--
Description:
Given: A consumer with byte credit N for a queue with messages Big size > N
and Small size < N
The consumer should not be able to consume Big. Now remove Big with a different
consumer.
The consumer should now be able to consume Small, but doesn't
The problem in Queue.cpp is twofold:
- if a consumer returns "false" from accept, it is assumed to be blocked and
is removed from the listener set. It won't be notified of new messages
- the queue only notifies when new messages arrive. It does not notify when a
blocking message is removed.
This is demonstrated by adding the following to test_credit_flow_bytes in
message.py:
# Check for bug that allowed a small message to be hidden by a larger
one.
session.message_transfer(message=Message(session.delivery_properties(routing_key="q"),
"toobigtoobigtoobigtoobig"))
session.message_transfer(message=Message(session.delivery_properties(routing_key="q"),
"abcdefgh"))
session.message_flow(unit = session.credit_unit.byte, value = msg_size,
destination = "c")
try:
q.get(timeout = 1) # Should fail, message is too big.
self.fail("Expected Empty exception")
except Empty: None
# Create another consumer to remove the large message
session.message_subscribe(queue = "q", destination = "c2")
session.message_flow(unit = session.credit_unit.byte, value =
0xL, destination = "c2")
session.message_flow(unit = session.credit_unit.message, value = 1,
destination = "c2")
self.assertDataEquals(session, session.incoming("c2").get(timeout=1),
"toobigtoobigtoobigtoobig")
# Now the first consumer should be able to receive the smaller message.
self.assertDataEquals(session, q.get(timeout = 1), "abcdefgh")
was:
Given: A consumer with byte credit N for a queue with messages Big size > N
and Small size < N
The consumer should not be able to consume Big. Now remove Big with a different
consumer.
The consumer should now be able to consume Small, but doesn't
The problem in Qpid.cpp is twofold:
- if a consumer returns "false" from accept, it is assumed to be blocked and
is removed from the listener set. It won't be notified of new messages
- the queue only notifies when new messages arrive. It does not notify when a
blocking message is removed.
This is demonstrated by adding the following to test_credit_flow_bytes in
message.py:
# Check for bug that allowed a small message to be hidden by a larger
one.
session.message_transfer(message=Message(session.delivery_properties(routing_key="q"),
"toobigtoobigtoobigtoobig"))
session.message_transfer(message=Message(session.delivery_properties(routing_key="q"),
"abcdefgh"))
session.message_flow(unit = session.credit_unit.byte, value = msg_size,
destination = "c")
try:
q.get(timeout = 1) # Should fail, message is too big.
self.fail("Expected Empty exception")
except Empty: None
# Create another consumer to remove the large message
session.message_subscribe(queue = "q", destination = "c2")
session.message_flow(unit = session.credit_unit.byte, value =
0xL, destination = "c2")
session.message_flow(unit = session.credit_unit.message, value = 1,
destination = "c2")
self.assertDataEquals(session, session.incoming("c2").get(timeout=1),
"toobigtoobigtoobigtoobig")
# Now the first consumer should be able to receive the smaller message.
self.assertDataEquals(session, q.get(timeout = 1), "abcdefgh")
> Consumer with byte credit can get ignored if a large message "eclipses" a
> small one.
>
>
> Key: QPID-1909
> URL: https://issues.apache.org
Re: What to do with client-api-example-tests.py ....
Jonathan Robie wrote: When I wrote client-api-example-tests.py, I assumed I was replacing the old validate scripts, using the new drain / spout examples, and using Python unittest. One developer says that's just what I should do, and tells me to integrate this into make check. Another says that only broker tests should be integrated into make check. Actually what I said was that make check is really only about C++ tests, and doesn't get run prior to java or python tests, so 'make check' isn't a suitable entry point for these tests. That's not to say they can't be integrated into make check, but putting them in there the same way the validate scripts were is really rather unfriendly to the non C++ developers as it forces them to sit through lots of irrelevant C++ tests in order to check interop. Also, it makes them much less useful as they can only be easily run against the software built out of the source tree. Interop tests are about more than just checking that a single snapshot is consistent, they are also about checking interop against prior versions of the software, and it's impossible to do this out of a single source tree. In its current form, it runs for 150 seconds. I can strip that down to less than a minute and still have very useful smoke tests for the client examples. What's the best approach? A. Add the tests, more or less as is, to make check B. Add a stripped down version to make check C. Use the tests, but don't add them to make check D. None of the above D In the long run, I can imagine having a very extensive version of this that tests interop using different AMQP versions, and tests every feature drain / spout support. We wouldn't want that to run with make check. Do we need a new make target for more extensive testing? I think you should forget about make and simply provide a convenient command line interface to running the tests (either via qpid-python-test or a custom script if appropriate). This can then be used to test interop outside of the source tree and can be trivially integrated by C++, Java, and/or python developers into their respective builds. --Rafael - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
What to do with client-api-example-tests.py ....
When I wrote client-api-example-tests.py, I assumed I was replacing the old validate scripts, using the new drain / spout examples, and using Python unittest. One developer says that's just what I should do, and tells me to integrate this into make check. Another says that only broker tests should be integrated into make check. In its current form, it runs for 150 seconds. I can strip that down to less than a minute and still have very useful smoke tests for the client examples. What's the best approach? A. Add the tests, more or less as is, to make check B. Add a stripped down version to make check C. Use the tests, but don't add them to make check D. None of the above In the long run, I can imagine having a very extensive version of this that tests interop using different AMQP versions, and tests every feature drain / spout support. We wouldn't want that to run with make check. Do we need a new make target for more extensive testing? Jonathan - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Closed: (QPID-2532) stale lock file
[ https://issues.apache.org/jira/browse/QPID-2532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway closed QPID-2532. - Resolution: Duplicate Closed as duplicate of QPID-2552 > stale lock file > --- > > Key: QPID-2532 > URL: https://issues.apache.org/jira/browse/QPID-2532 > Project: Qpid > Issue Type: Test > Components: C++ Broker >Affects Versions: 0.7 > Environment: Fedora Rawhide >Reporter: Jan Sarenik >Assignee: Alan Conway > Fix For: 0.7 > > Attachments: cluster0.log, core-analyze-1.txt > > > This happents quite regularly in last week but still pretty randomly > (sometimes whole make checks works well on the same revision > on which it did not a while ago). I do `rm -rf ~/.qpidd; qpid clean -xfd' > before every compilation. And still cluster_read_credit test fails because > of following error: > (relevant part of `make check' output follows) > 2010-04-22 11:54:31 warning Connection closed > 2010-04-22 11:54:31 warning Connect failed: Connection refused > 2010-04-22 11:54:31 warning Connection closed > Failed: Cannot establish a connection > 2010-04-22 11:54:31 critical Unexpected error: Removing stale lock file > /home/jsarenik/.qpidd/qpidd.41519.pid > Errors stopping brokers on ports: 41519 > FAIL: cluster_read_credit -- 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] Issue Comment Edited: (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-tabpanel&focusedCommentId=12890827#action_12890827 ] Alan Conway edited comment on QPID-2473 at 7/21/10 3:05 PM: The link error above was fixed for fedora 13 in revision 960894 Author: Alan Conway Date: Tue Jul 6 09:16:02 2010 Fix link error on fedora 13 Removed duplicate .o files linked with cluster_test executable. git-svn-id: https://svn.apache.org/repos/asf/qpid/tr...@960894 13f79535-47bb-0310-9956-ffa450edef68 Can you confirm if it builds for you? was (Author: aconway): The link error above was fixed for fedora 13 in revision 960894 Author: Alan Conway Date: Tue Jul 6 09:16:02 2010 Fix link error on fedora 13 Removed duplicate .o files linked with cluster_test executable. git-svn-id: https://svn.apache.org/repos/asf/qpid/tr...@960894 13f79535-47bb-0310-9956-ffa450edef68 > 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] 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-tabpanel&focusedCommentId=12890827#action_12890827 ] Alan Conway commented on QPID-2473: --- The link error above was fixed for fedora 13 in revision 960894 Author: Alan Conway Date: Tue Jul 6 09:16:02 2010 Fix link error on fedora 13 Removed duplicate .o files linked with cluster_test executable. git-svn-id: https://svn.apache.org/repos/asf/qpid/tr...@960894 13f79535-47bb-0310-9956-ffa450edef68 > 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
RE: 0-10 Session Close and Failover
I don't think there was ever any issue observed with the C++ clients, just that the Java 0-10 client failover (tests, against the C++ broker IIRC) stopped working properly when AMQSession_0_10 was changed to create a Session with 0 as the timeout in the Session constructor as opposed to the 1 normally used in AMQSession_0_10. This was done to match the 0 that the client actually always sends to the broker when attaching regardless of the real value (1) it considers the expiry variable to be, but that meant the Session always transitioned to the closed state instead of just detached, which the failover (tests) depends on. The reason the previous change was made was so that when the broker asks the client to close the session (eg following management user intervention) it actually would instead of just sitting in the detached state. The changes you are proposing seem like they should make it so that when the broker tells the client to set its timeout to 0 before detaching it actually does it instead of just ignoring it, thereby making it transition to the closed state instead of just detached. Robbie > -Original Message- > From: Andrew Kennedy [mailto:andrewinternatio...@gmail.com] > Sent: 21 July 2010 17:14 > To: dev@qpid.apache.org > Subject: 0-10 Session Close and Failover > > Hi. > > I have been looking at the 0-10 session close semantics, and been > meaning to ask this for a while... > > There is no explicit close message in 0-10, rather the session timeout > is supposed to be set to 0 seconds and then a session detach message > is sent. I have implemented this, since it requires simply creating a > handler for sessionRequestTimeout messages that actually sets expiry > to 0, as discussed on QPID-2586 and in this message on the dev list: > http://apache-qpid-developers.2158895.n2.nabble.com/Java-0-10-Session- > closure-expiry-timeout-td4865744.html#a4865744 > > Also, see comments in the code (in o.a.q.t.Session.java): > > // XXX: when the broker and client support full session > // recovery we should use expiry as the requested timeout > > // XXX: we manually set the expiry to zero here to > // simulate full session recovery in brokers that don't > // support it, we should remove this line when there is > // broker support for full session resume: > expiry = 0; > > which is exactly what I have done, I use the expiry field (therefore > on session create the timeout is set to 1 on both sides now) and (in > o.a.q.t.SessionDelegate.java) we have: > > // XXX: we ignore this right now, we should uncomment this > // when full session resume is supported: > > where I have uncommented the line following, which just calls > ssn.setExpiry(t.getTimeout()) and done the same in the new handler > for sessionRequestTimeout. > > I believe that this is a fairly simple and non-contentious change. One > thing that I noticed from other dev list messages is that this could > affect the failover mechanism used by the C++ clients. I ran the cpp > test suite with my changes and noticed no difference, but then I > couldn't see what tests would actually be affected. Can anyone shged > more light on the problems I might expect or be missing? > > Thanks, > Andrew. > -- > -- andrew d kennedy ? edinburgh : +44 7941 197 134 > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: 0-10 Session Close and Failover
On 07/21/2010 12:14 PM, Andrew Kennedy wrote: Hi. I have been looking at the 0-10 session close semantics, and been meaning to ask this for a while... There is no explicit close message in 0-10, rather the session timeout is supposed to be set to 0 seconds and then a session detach message is sent. I have implemented this, since it requires simply creating a handler for sessionRequestTimeout messages that actually sets expiry to 0, as discussed on QPID-2586 and in this message on the dev list: http://apache-qpid-developers.2158895.n2.nabble.com/Java-0-10-Session-closure-expiry-timeout-td4865744.html#a4865744 Also, see comments in the code (in o.a.q.t.Session.java): // XXX: when the broker and client support full session // recovery we should use expiry as the requested timeout // XXX: we manually set the expiry to zero here to // simulate full session recovery in brokers that don't // support it, we should remove this line when there is // broker support for full session resume: expiry = 0; which is exactly what I have done, I use the expiry field (therefore on session create the timeout is set to 1 on both sides now) and (in o.a.q.t.SessionDelegate.java) we have: // XXX: we ignore this right now, we should uncomment this // when full session resume is supported: where I have uncommented the line following, which just calls ssn.setExpiry(t.getTimeout()) and done the same in the new handler for sessionRequestTimeout. I believe that this is a fairly simple and non-contentious change. One thing that I noticed from other dev list messages is that this could affect the failover mechanism used by the C++ clients. I ran the cpp test suite with my changes and noticed no difference, but then I couldn't see what tests would actually be affected. Can anyone shged more light on the problems I might expect or be missing? The C++ client fails-over on disconnect, there's currently no per-session failover. I don't see a problem with your proposal for c++ clients. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2720) Qpid broker can not run inside an OSGi container
[ https://issues.apache.org/jira/browse/QPID-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12890767#action_12890767 ] Sorin Suciu commented on QPID-2720: --- Hi Danushka, We already have an org.apache.qpid.server.virtualhost.plugin.Activator which would be called by OSGI. Could we implement the same logic like you have in QpidActivator (eg detect whether we are embedded in an OSGI framework and proceed accordingly)? This would avoid duplication and make things clearer and cleaner. We could possibly move it to a different package in the future to eliminate any confusion. How do you plan to start the broker and process the configuration? Lets have a chat on the list on this topic. Thanks, Sorin > Qpid broker can not run inside an OSGi container > > > Key: QPID-2720 > URL: https://issues.apache.org/jira/browse/QPID-2720 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Danushka Menikkumbura >Assignee: Danushka Menikkumbura > Attachments: QPID-2720-V2.patch, QPID-2720.patch > > -- 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] Resolved: (QPID-2741) DerbyMessageStore is not shut down when told to close
[ https://issues.apache.org/jira/browse/QPID-2741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-2741. -- Resolution: Fixed > DerbyMessageStore is not shut down when told to close > - > > Key: QPID-2741 > URL: https://issues.apache.org/jira/browse/QPID-2741 > Project: Qpid > Issue Type: Bug > Components: Java Broker MessageStore - DerbyStore >Affects Versions: 0.5, 0.6 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.7 > > > DerbyMessageStore is not shut down when told to close. The close() method > just logs the store closure, but the database is not actually shut down. -- 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] Resolved: (QPID-2731) enable getting/setting queue exclusivity property via the JMX management interface
[ https://issues.apache.org/jira/browse/QPID-2731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-2731. -- Resolution: Fixed > enable getting/setting queue exclusivity property via the JMX management > interface > -- > > Key: QPID-2731 > URL: https://issues.apache.org/jira/browse/QPID-2731 > Project: Qpid > Issue Type: Improvement > Components: Java Broker, Java Management : JMX Interface >Affects Versions: 0.7 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.7 > > > enable getting/setting the queue exclusivity property via the JMX management > interface -- 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
0-10 Session Close and Failover
Hi. I have been looking at the 0-10 session close semantics, and been meaning to ask this for a while... There is no explicit close message in 0-10, rather the session timeout is supposed to be set to 0 seconds and then a session detach message is sent. I have implemented this, since it requires simply creating a handler for sessionRequestTimeout messages that actually sets expiry to 0, as discussed on QPID-2586 and in this message on the dev list: http://apache-qpid-developers.2158895.n2.nabble.com/Java-0-10-Session-closure-expiry-timeout-td4865744.html#a4865744 Also, see comments in the code (in o.a.q.t.Session.java): // XXX: when the broker and client support full session // recovery we should use expiry as the requested timeout // XXX: we manually set the expiry to zero here to // simulate full session recovery in brokers that don't // support it, we should remove this line when there is // broker support for full session resume: expiry = 0; which is exactly what I have done, I use the expiry field (therefore on session create the timeout is set to 1 on both sides now) and (in o.a.q.t.SessionDelegate.java) we have: // XXX: we ignore this right now, we should uncomment this // when full session resume is supported: where I have uncommented the line following, which just calls ssn.setExpiry(t.getTimeout()) and done the same in the new handler for sessionRequestTimeout. I believe that this is a fairly simple and non-contentious change. One thing that I noticed from other dev list messages is that this could affect the failover mechanism used by the C++ clients. I ran the cpp test suite with my changes and noticed no difference, but then I couldn't see what tests would actually be affected. Can anyone shged more light on the problems I might expect or be missing? Thanks, Andrew. -- -- andrew d kennedy ? edinburgh : +44 7941 197 134 - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-2742) DerbyMessageStore createExchange() method does not function
[ https://issues.apache.org/jira/browse/QPID-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-2742. -- Resolution: Fixed > DerbyMessageStore createExchange() method does not function > --- > > Key: QPID-2742 > URL: https://issues.apache.org/jira/browse/QPID-2742 > Project: Qpid > Issue Type: Bug > Components: Java Broker MessageStore - DerbyStore >Affects Versions: 0.6 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.7 > > > DerbyMessageStore createExchange() method does not function. There 2 > statement executions (of the same statement) with a closure inbetween and so > the latter execution fails. Additionally the exchange type is incorrectly > toString()'d into the field and so sets the wrong valule into the store, > which leads to recovery failure. -- 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
want to help
Hi Everyone, My name is Yogesh, I started using QPID Java Broker recently where my Product needed to support QPID as a JMS Broker. I really like the way it implements the AMQP spec and the ease of it to use it as broker. I started with QPID Version 0.5 and the 0.6 and was stuck with the XA related issues with Java Broker where Robert Godfrey suggested that it is yet to be supported in response to my query on discussion forum. I have the QPID trunk development environment setup for compilation and build (went through the Building QPID) I would love to take part in the Java Implementation and releases with my support as required for the various tasks you guys working on. I will get better understanding into the architecture and implementation with my experience with it, do let me know how I should proceed or if there is anything where you feel need supporting hand. I appreciate the efforts on this Product and sure about the simplicity it provides as a JMS Broker. Thanks, Yogesh
[jira] Created: (QPID-2753) Add frame capacity checks to JMS property setting to ensure AMQP compliance.
Add frame capacity checks to JMS property setting to ensure AMQP compliance. Key: QPID-2753 URL: https://issues.apache.org/jira/browse/QPID-2753 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.6 Reporter: Martin Ritchie The header frame is a fixed size and currently it is possible to put more data in to it than the AMQP specification says should be allowed. In Qpid this does not matter as the Broker will read these extra large header frames. However, other brokers may not be so gracious. We should throw an execption to the user when their data addition to the headers will put their current message over the defined framesize. Quite what the impact this would be on the broker if it receives a message from a client with a large frame size and has to send to a client with a small frame size. As a result this should be a configurable option for when we are running Qpid-Qpid. -- 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-2752) Cannot create LVQ's using the JMS client.
[ https://issues.apache.org/jira/browse/QPID-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12890612#action_12890612 ] Martin Ritchie commented on QPID-2752: -- Hi, As far as I can see if you set the following properties/arguments on your queue declare then it should work: "qpid.last_value_queue" "qpid.last_value_queue_key" Sounds like the bug is in the new addressing format processing if it cannot correctly pull out properties. I see ConflationQueueTest is excluded from the CPP broker. Would be good to make it work. > Cannot create LVQ's using the JMS client. > - > > Key: QPID-2752 > URL: https://issues.apache.org/jira/browse/QPID-2752 > Project: Qpid > Issue Type: Bug > Components: Java Client >Reporter: Rajith Attapattu >Assignee: Rajith Attapattu > Fix For: 0.7 > > > A JMS client should be able to create an LVQ using the new addressing format. > However currently it's not possible due to a bug in extracting the right > information. > It would also be nice to add test cases from the JMS client side to avoid any > regressions in the future. -- 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
