[jira] Commented: (QPID-1811) Unable to compile qpid on FreeBSD
[ https://issues.apache.org/jira/browse/QPID-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13006879#comment-13006879 ] Sudip Kumar Panda commented on QPID-1811: - Thanks Steve. Since the defect was filed for failure on freebsd build and the defect is resolved, I thought all the issues are resolved. Probably, I can spend some of my time (when free) to write lower level poller code. Unable to compile qpid on FreeBSD - Key: QPID-1811 URL: https://issues.apache.org/jira/browse/QPID-1811 Project: Qpid Issue Type: Sub-task Components: C++ Broker Affects Versions: 0.6 Environment: FreeBSD 8-CURRENT on amd64 (64 bit) $ g++ -v Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] $ python -V Python 2.6.1 $ pkg_info | grep boost boost-python-1.37.0 Free peer-reviewed portable C++ source libraries svn trunk version, checked out now (r765092) ./configure CPPFLAGS=-I/usr/local/include -L/usr/local/lib LDFLAGS=-L/usr/local/lib --with-poller=poll Reporter: Attila Nagy Assignee: Andrew Stitcher Priority: Critical Fix For: 0.7 Attachments: freebsd.patch, qpidfbsdcompile.diff, sasl.diff I'm trying to build qpid c++ broker on FreeBSD. Problems found during the build process: -8- g++ -DHAVE_CONFIG_H -I. -Igen -I./gen -I/usr/local/include -Werror -pedantic -Wall -Wextra -Wno-shadow -Wpointer-arith -Wcast-qual -Wcast-align -Wno-long-long -Wvolatile-register-var -Winvalid-pch -Wno-system-headers -Woverloaded-virtual -g -O2 -MT qpid/sys/posix/Thread.lo -MD -MP -MF qpid/sys/posix/.deps/Thread.Tpo -c qpid/sys/posix/Thread.cpp -fPIC -DPIC -o qpid/sys/posix/.libs/Thread.o qpid/sys/posix/Thread.cpp: In member function 'long unsigned int qpid::sys::Thread::id()': qpid/sys/posix/Thread.cpp:64: error: invalid conversion from 'pthread*' to 'long unsigned int' I don't know whether it helps during the run, but allows to compile: return (unsigned long)impl-thread; -8- g++ -DHAVE_CONFIG_H -I. -Igen -I./gen -I/usr/local/include -Werror -pedantic -Wall -Wextra -Wno-shadow -Wpointer-arith -Wcast-qual -Wcast-align -Wno-long-long -Wvolatile-register-var -Winvalid-pch -Wno-system-headers -Woverloaded-virtual -g -O2 -MT qpid/sys/posix/SystemInfo.lo -MD -MP -MF qpid/sys/posix/.deps/SystemInfo.Tpo -c qpid/sys/posix/SystemInfo.cpp -fPIC -DPIC -o qpid/sys/posix/.libs/SystemInfo.o In file included from qpid/sys/posix/SystemInfo.cpp:25: /usr/include/net/if.h:293: error: field 'ifru_addr' has incomplete type /usr/include/net/if.h:294: error: field 'ifru_dstaddr' has incomplete type /usr/include/net/if.h:295: error: field 'ifru_broadaddr' has incomplete type /usr/include/net/if.h:327: error: field 'ifra_addr' has incomplete type /usr/include/net/if.h:328: error: field 'ifra_broadaddr' has incomplete type /usr/include/net/if.h:329: error: field 'ifra_mask' has incomplete type /usr/include/net/if.h:427: error: field 'addr' has incomplete type /usr/include/net/if.h:428: error: field 'dstaddr' has incomplete type qpid/sys/posix/SystemInfo.cpp: In function 'void qpid::sys::SystemInfo::getLocalIpAddresses(uint16_t, std::vectorqpid::Address, std::allocatorqpid::Address )': qpid/sys/posix/SystemInfo.cpp:63: error: 'PF_INET' was not declared in this scope qpid/sys/posix/SystemInfo.cpp:63: error: 'SOCK_STREAM' was not declared in this scope qpid/sys/posix/SystemInfo.cpp:63: error: 'socket' was not declared in this scope qpid/sys/posix/SystemInfo.cpp:66: error: 'struct ifreq' has no member named 'ifr_ifindex' qpid/sys/posix/SystemInfo.cpp:67: error: 'SIOCGIFNAME' was not declared in this scope qpid/sys/posix/SystemInfo.cpp:72: error: 'union ifreq::anonymous' has no member named 'ifru_addr' qpid/sys/posix/SystemInfo.cpp:73: error: invalid use of incomplete type 'struct qpid::sys::sockaddr_in' qpid/sys/posix/SystemInfo.cpp:72: error: forward declaration of 'struct qpid::sys::sockaddr_in' The incomplete type error can be fixed by including sys/socket.h before net/if.h. The 'struct ifreq' has no member named 'ifr_ifindex' can be fixed by: #ifdef __FreeBSD__ ifr.ifr_index = i; #else ifr.ifr_ifindex = i; #endif The 'SIOCGIFNAME' was not declared in this scope is hopefully solved by: #ifdef SIOCGIFNAME if (::ioctl (s, SIOCGIFNAME, ifr) 0) #else if (!if_indextoname(ifr.ifr_index, ifr.ifr_name))
Re: Request to include QPID-3143 in the 0.10 release
I feel that this change should not be included in the 0.10 release. I think we are too close to release (RC1 is due tomorrow yes?) and that there isnt significant enough testing in this area to provide enough confidence when making what is actually an appreciable change in client behaviour at this stage. So far as I can tell from the quick look I've taken so far AddressBasedDestinationTest is the only test which exercises the Addressing code to any extent, and does so often by prefixing the address strings with 'ADDR:' because the test profiles are all running set to use the old BindingURL syntax. As a result it would seem we ultimately arent testing the precise execution paths for many operations users will undertake at all. Robbie On 14 March 2011 16:48, Rajith Attapattu rajit...@gmail.com wrote: The attached patch in QPID-3143 contains a simple one line fix and a modified test case to test the change. The same is committed to trunk at rev 1081460. The fix is low risk IMHO. However the fix is important as it makes the session.createQueue method spec complaint. It also allows the default behaviour to be easily overridden if the user chooses do so. Regards, Rajith
Re: Request to include QPID-3143 in the 0.10 release
On Tue, Mar 15, 2011 at 12:08 PM, Robbie Gemmell robbie.gemm...@gmail.comwrote: I feel that this change should not be included in the 0.10 release. I think we are too close to release (RC1 is due tomorrow yes?) and that there isnt significant enough testing in this area to provide enough confidence when making what is actually an appreciable change in client behaviour at this stage. I actually disagree with your assessment. I certainly consider this a **very low risk** change, given that addressing is the *default*. The only difference here is that the create option is not selected and the impact of that is an exception will be thrown if the queue is not present. There is absolutely no other **extra** risk involved here. The risk you perceive here is the impact of the addressing implementation due to lack of tests which is a valid concern. However that risk is there whether or not this commit is included or not. This commit does not include anymore risk in the client than what is already there due to addressing being the default. Does that make sense ? Do you agree with that ? So far as I can tell from the quick look I've taken so far AddressBasedDestinationTest is the only test which exercises the Addressing code to any extent, and does so often by prefixing the address strings with 'ADDR:' because the test profiles are all running set to use the old BindingURL syntax. As a result it would seem we ultimately arent testing the precise execution paths for many operations users will undertake at all. This is one of the biggest obstacles I had when testing the new address based implementation. Switching the default will create many test failures that is impossible to handle on my own. Also switching the default is not a good solution either as we still support the older binding URL mechanism as well. The addressing scheme actually exercised code paths in a certain way that it highlighted several race conditions, a few dead locks and many other errors that were there in the code base for a long time. Therefore it would have been nice had I been able to catch these issues using our test suites. Ex issues in durable subscribers, queue receivers etc.. I also believe this highlights a weakness in a our test suite - all though this is separate discussion on it's own. We should probably try to use the JMS interfaces as much as possible when writing our integration tests and have enough provisions to abstract out as many details as possible. This allows us to easily configure a single test to run under different configurations. Rajith Robbie On 14 March 2011 16:48, Rajith Attapattu rajit...@gmail.com wrote: The attached patch in QPID-3143 contains a simple one line fix and a modified test case to test the change. The same is committed to trunk at rev 1081460. The fix is low risk IMHO. However the fix is important as it makes the session.createQueue method spec complaint. It also allows the default behaviour to be easily overridden if the user chooses do so. Regards, Rajith
Re: Request to include QPID-3143 in the 0.10 release
I see both side here, I think the fundamental issue for me is that I hadn't previously picked up that when the change to the default addressing syntax was changed in the 0.8 release, the tests were made to explicitly run with the Binding URL as the default. As such we are not exposing the default that we are giving to users when we run the tests - thus the expected normal code path is not being exercised in our tests other than in the one test that Robbie highlighted (and this uses the explicit ADDR: syntax). As such I don't feel like simply running the tests gives me the confidence that this change will not have unforseen consequences. In truth I actually now feel quite nervous about what we did in 0.8. I strongly feel that we should update the tests to use the default (which is now ADDR) syntax - changing any test where the BindingURL is implicitly expected. Given that this is a change rather than a bug fix, the fact that we are supposed to be in code freeze in preparation for release, and that I don't have confidence that we are adequately testing the default behaviour using the standard tests - I don't feel that it is appropriate to include in 0.10. -- Rob On 15 March 2011 16:34, Rajith Attapattu rajit...@gmail.com wrote: On Tue, Mar 15, 2011 at 12:08 PM, Robbie Gemmell robbie.gemm...@gmail.comwrote: I feel that this change should not be included in the 0.10 release. I think we are too close to release (RC1 is due tomorrow yes?) and that there isnt significant enough testing in this area to provide enough confidence when making what is actually an appreciable change in client behaviour at this stage. I actually disagree with your assessment. I certainly consider this a **very low risk** change, given that addressing is the *default*. The only difference here is that the create option is not selected and the impact of that is an exception will be thrown if the queue is not present. There is absolutely no other **extra** risk involved here. The risk you perceive here is the impact of the addressing implementation due to lack of tests which is a valid concern. However that risk is there whether or not this commit is included or not. This commit does not include anymore risk in the client than what is already there due to addressing being the default. Does that make sense ? Do you agree with that ? So far as I can tell from the quick look I've taken so far AddressBasedDestinationTest is the only test which exercises the Addressing code to any extent, and does so often by prefixing the address strings with 'ADDR:' because the test profiles are all running set to use the old BindingURL syntax. As a result it would seem we ultimately arent testing the precise execution paths for many operations users will undertake at all. This is one of the biggest obstacles I had when testing the new address based implementation. Switching the default will create many test failures that is impossible to handle on my own. Also switching the default is not a good solution either as we still support the older binding URL mechanism as well. The addressing scheme actually exercised code paths in a certain way that it highlighted several race conditions, a few dead locks and many other errors that were there in the code base for a long time. Therefore it would have been nice had I been able to catch these issues using our test suites. Ex issues in durable subscribers, queue receivers etc.. I also believe this highlights a weakness in a our test suite - all though this is separate discussion on it's own. We should probably try to use the JMS interfaces as much as possible when writing our integration tests and have enough provisions to abstract out as many details as possible. This allows us to easily configure a single test to run under different configurations. Rajith Robbie On 14 March 2011 16:48, Rajith Attapattu rajit...@gmail.com wrote: The attached patch in QPID-3143 contains a simple one line fix and a modified test case to test the change. The same is committed to trunk at rev 1081460. The fix is low risk IMHO. However the fix is important as it makes the session.createQueue method spec complaint. It also allows the default behaviour to be easily overridden if the user chooses do so. Regards, Rajith
Re: Request to include QPID-3143 in the 0.10 release
On 15 March 2011 16:34, Rajith Attapattu rajit...@gmail.com wrote: On Tue, Mar 15, 2011 at 12:08 PM, Robbie Gemmell robbie.gemm...@gmail.com wrote: I feel that this change should not be included in the 0.10 release. I think we are too close to release (RC1 is due tomorrow yes?) and that there isnt significant enough testing in this area to provide enough confidence when making what is actually an appreciable change in client behaviour at this stage. I actually disagree with your assessment. I certainly consider this a **very low risk** change, given that addressing is the *default*. Addressing already being the default makes me less inclined to change it than if it wasn't, not the other way around. The only difference here is that the create option is not selected and the impact of that is an exception will be thrown if the queue is not present. There is absolutely no other **extra** risk involved here. The risk you perceive here is the impact of the addressing implementation due to lack of tests which is a valid concern. However that risk is there whether or not this commit is included or not. There is risk that this commit will introduce behaviour that we have not accounted for, which can/will not show up in our test suite because we are not testing the code in the manner that users will actually use it. Whether the addressing implementation has pre-existing issues undetected by the current tests is also unknown, but that is an entirely different concern than this issue. There is a clearly seperate risk that making this change will introduce unforseen issues. This commit does not include anymore risk in the client than what is already there due to addressing being the default. Does that make sense ? Do you agree with that ? So far as I can tell from the quick look I've taken so far AddressBasedDestinationTest is the only test which exercises the Addressing code to any extent, and does so often by prefixing the address strings with 'ADDR:' because the test profiles are all running set to use the old BindingURL syntax. As a result it would seem we ultimately arent testing the precise execution paths for many operations users will undertake at all. This is one of the biggest obstacles I had when testing the new address based implementation. Switching the default will create many test failures that is impossible to handle on my own. Also switching the default is not a good solution either as we still support the older binding URL mechanism as well. I had not fully appreciated the extent to which the BURL addressing was being used in the testing profiles, and would not have been comfortable making the switch in default addressing syntax for 0.8 had I known. We absolutely need to be having the majority of our testing concentrated on the default behaviour users will encounter as to do otherwise is somewhat silly, and the fact we arent testing much of the default behaviour at all is fairly ridiculous. The addressing scheme actually exercised code paths in a certain way that it highlighted several race conditions, a few dead locks and many other errors that were there in the code base for a long time. Therefore it would have been nice had I been able to catch these issues using our test suites. Ex issues in durable subscribers, queue receivers etc.. I also believe this highlights a weakness in a our test suite - all though this is separate discussion on it's own. We should probably try to use the JMS interfaces as much as possible when writing our integration tests and have enough provisions to abstract out as many details as possible. This allows us to easily configure a single test to run under different configurations. Rajith Robbie On 14 March 2011 16:48, Rajith Attapattu rajit...@gmail.com wrote: The attached patch in QPID-3143 contains a simple one line fix and a modified test case to test the change. The same is committed to trunk at rev 1081460. The fix is low risk IMHO. However the fix is important as it makes the session.createQueue method spec complaint. It also allows the default behaviour to be easily overridden if the user chooses do so. Regards, Rajith
Re: Request to include QPID-3143 in the 0.10 release
On Tue, Mar 15, 2011 at 1:24 PM, Robert Godfrey rob.j.godf...@gmail.comwrote: I see both side here, I think the fundamental issue for me is that I hadn't previously picked up that when the change to the default addressing syntax was changed in the 0.8 release, the tests were made to explicitly run with the Binding URL as the default. As such we are not exposing the default that we are giving to users when we run the tests - thus the expected normal code path is not being exercised in our tests other than in the one test that Robbie highlighted (and this uses the explicit ADDR: syntax). As such I don't feel like simply running the tests gives me the confidence that this change will not have unforseen consequences. In truth I actually now feel quite nervous about what we did in 0.8. I strongly feel that we should update the tests to use the default (which is now ADDR) syntax - changing any test where the BindingURL is implicitly expected. Given that this is a change rather than a bug fix, the fact that we are supposed to be in code freeze in preparation for release, and that I don't have confidence that we are adequately testing the default behaviour using the standard tests - I don't feel that it is appropriate to include in 0.10. I actually consider this a bug as I didn't really implement what I should have in the first place. The current behaviour is neither backwards compatible nor correct as per the JMS spec. As for your comments about the tests, I fully agree with you and have said the same in my response to Robbie with some examples. But as I mentioned, that risk is **already there in 0.10** and this commit is not adding anything to it. Rajith -- Rob On 15 March 2011 16:34, Rajith Attapattu rajit...@gmail.com wrote: On Tue, Mar 15, 2011 at 12:08 PM, Robbie Gemmell robbie.gemm...@gmail.comwrote: I feel that this change should not be included in the 0.10 release. I think we are too close to release (RC1 is due tomorrow yes?) and that there isnt significant enough testing in this area to provide enough confidence when making what is actually an appreciable change in client behaviour at this stage. I actually disagree with your assessment. I certainly consider this a **very low risk** change, given that addressing is the *default*. The only difference here is that the create option is not selected and the impact of that is an exception will be thrown if the queue is not present. There is absolutely no other **extra** risk involved here. The risk you perceive here is the impact of the addressing implementation due to lack of tests which is a valid concern. However that risk is there whether or not this commit is included or not. This commit does not include anymore risk in the client than what is already there due to addressing being the default. Does that make sense ? Do you agree with that ? So far as I can tell from the quick look I've taken so far AddressBasedDestinationTest is the only test which exercises the Addressing code to any extent, and does so often by prefixing the address strings with 'ADDR:' because the test profiles are all running set to use the old BindingURL syntax. As a result it would seem we ultimately arent testing the precise execution paths for many operations users will undertake at all. This is one of the biggest obstacles I had when testing the new address based implementation. Switching the default will create many test failures that is impossible to handle on my own. Also switching the default is not a good solution either as we still support the older binding URL mechanism as well. The addressing scheme actually exercised code paths in a certain way that it highlighted several race conditions, a few dead locks and many other errors that were there in the code base for a long time. Therefore it would have been nice had I been able to catch these issues using our test suites. Ex issues in durable subscribers, queue receivers etc.. I also believe this highlights a weakness in a our test suite - all though this is separate discussion on it's own. We should probably try to use the JMS interfaces as much as possible when writing our integration tests and have enough provisions to abstract out as many details as possible. This allows us to easily configure a single test to run under different configurations. Rajith Robbie On 14 March 2011 16:48, Rajith Attapattu rajit...@gmail.com wrote: The attached patch in QPID-3143 contains a simple one line fix and a modified test case to test the change. The same is committed to trunk at rev 1081460. The fix is low risk IMHO. However the fix is important as it makes the session.createQueue method spec complaint. It also allows the default behaviour to be easily overridden if the user chooses do so. Regards, Rajith
[jira] Updated: (QPID-3076) Enable producer flow control (QPID-2935) in a cluster
[ https://issues.apache.org/jira/browse/QPID-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated QPID-3076: - Affects Version/s: 0.10 Fix Version/s: (was: 0.9) 0.11 Enable producer flow control (QPID-2935) in a cluster - Key: QPID-3076 URL: https://issues.apache.org/jira/browse/QPID-3076 Project: Qpid Issue Type: New Feature Components: C++ Clustering Affects Versions: 0.9, 0.10 Reporter: Alan Conway Assignee: Ken Giusti Fix For: 0.11 QPID-2935 adds producer flow control to the broker, but it is disabled in a cluster. Flow control adds additional broker state that must be replicated in a cluster in order to maintain cluster consistency. Add this replication and enable flow control in a cluster. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-3144) qpidd --check does not work with info logging and --log-to-stdout=yes
[ https://issues.apache.org/jira/browse/QPID-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13007042#comment-13007042 ] michael j. goulish commented on QPID-3144: -- Fixing this in the code seems too heavy-handed. Also, the log message that is getting in the way is presumably useful in other contexts. Wouldn't it be better to simply do something like the following in the affected scripts? my_pid=`qpidd --check | grep -v Loaded` I would propose that we leave this small change out. qpidd --check does not work with info logging and --log-to-stdout=yes - Key: QPID-3144 URL: https://issues.apache.org/jira/browse/QPID-3144 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.9 Reporter: Alan Conway Assignee: Alan Conway Priority: Minor Fix For: 0.10 qpidd --check is supposed to print the PID of a running qpidd --daemon, for use in scripts and the like. However with info logging and log-to-stdout enabled this does not work because log messages of the form: 2011-03-14 16:21:05 info Loaded Module: /usr/lib64/qpid/daemon/cluster.so precede the port number. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Request to include QPID-3143 in the 0.10 release
On 15 March 2011 17:33, Rajith Attapattu rajit...@gmail.com wrote: On Tue, Mar 15, 2011 at 1:24 PM, Robert Godfrey rob.j.godf...@gmail.comwrote: I see both side here, I think the fundamental issue for me is that I hadn't previously picked up that when the change to the default addressing syntax was changed in the 0.8 release, the tests were made to explicitly run with the Binding URL as the default. As such we are not exposing the default that we are giving to users when we run the tests - thus the expected normal code path is not being exercised in our tests other than in the one test that Robbie highlighted (and this uses the explicit ADDR: syntax). As such I don't feel like simply running the tests gives me the confidence that this change will not have unforseen consequences. In truth I actually now feel quite nervous about what we did in 0.8. I strongly feel that we should update the tests to use the default (which is now ADDR) syntax - changing any test where the BindingURL is implicitly expected. Given that this is a change rather than a bug fix, the fact that we are supposed to be in code freeze in preparation for release, and that I don't have confidence that we are adequately testing the default behaviour using the standard tests - I don't feel that it is appropriate to include in 0.10. I actually consider this a bug as I didn't really implement what I should have in the first place. The current behaviour is neither backwards compatible nor correct as per the JMS spec. As for your comments about the tests, I fully agree with you and have said the same in my response to Robbie with some examples. But as I mentioned, that risk is **already there in 0.10** and this commit is not adding anything to it. Rajith In my mind this is a 'feature' change rather than bug fix as the patch would alter a behaviour of the client that was, correctly or otherwise, long since put there deliberately and which you preserved deliberately. You are correct that there is existing risk already in 0.10, however this is an additional change which would clearly introduce an additional risk of unforseen effects in its own right versus not including it. Not having enough confidence in the existing situation is no reason to throw caustion to the wind. Robbie
Re: Request to include QPID-3143 in the 0.10 release
I actually consider this a bug as I didn't really implement what I should have in the first place. The current behaviour is neither backwards compatible nor correct as per the JMS spec. I think talking about the JMS spec here is a bit of a Red Herring... The change here is regarding the nature of the object returned by createQueue(...). Both the before and after are compliant with the spec as the spec treats nature of the object returned as completely opaque. On could argue that being able to create and Destination Object which upon creation of a producer or consumer which references the Destination causes the an entity (Queue) to be created on the Broker as non-compliant, or at least not within the spirit of the JMS spec... but even after your change this would still be the case if you include the necessary options in the supplied address String. As for your comments about the tests, I fully agree with you and have said the same in my response to Robbie with some examples. But as I mentioned, that risk is **already there in 0.10** Clearly there is a risk in 0.10 (an in 0.8) and if I had properly investigated at the time of the 0.8 release I would have argued that we should not have changed the default without changing the tests - this was an omission on my part which I apologies for. Having said that, my expectation of a code freeze in anticipation of a release is that we should only be committing urgent and necessary changes, or changes of a very low risk and high utility. For me this sadly does not meet that bar (I do want to see this behaviour in Qpid, as I've previously said). and this commit is not adding anything to it. The problem is that we cannot properly prove that this is not increasing the risk, as we have no tests that actually use the default behaviour... the only tests explicitly use the ADDR syntax since we change the default in the test runs to Binding URL. I think this patch should be made to trunk immediately, and a new JIRA should be raised to change the test runner so it uses the default default. As previously I would not have object to this in isolation if it had been part of the original check-in... but we really should be trying to maintain some discipline once we have announced a freeze. I also recommend that we should probably have some sort of WARNING log message generated on the client if they try to create a destination based on a String which does not explicitly define which syntax it is using since we keep changing the behaviour associated with this option. Users need to be explicitly stating their intent so they are not surprised by our changes in behaviour. -- Rob Rajith -- Rob On 15 March 2011 16:34, Rajith Attapattu rajit...@gmail.com wrote: On Tue, Mar 15, 2011 at 12:08 PM, Robbie Gemmell robbie.gemm...@gmail.comwrote: I feel that this change should not be included in the 0.10 release. I think we are too close to release (RC1 is due tomorrow yes?) and that there isnt significant enough testing in this area to provide enough confidence when making what is actually an appreciable change in client behaviour at this stage. I actually disagree with your assessment. I certainly consider this a **very low risk** change, given that addressing is the *default*. The only difference here is that the create option is not selected and the impact of that is an exception will be thrown if the queue is not present. There is absolutely no other **extra** risk involved here. The risk you perceive here is the impact of the addressing implementation due to lack of tests which is a valid concern. However that risk is there whether or not this commit is included or not. This commit does not include anymore risk in the client than what is already there due to addressing being the default. Does that make sense ? Do you agree with that ? So far as I can tell from the quick look I've taken so far AddressBasedDestinationTest is the only test which exercises the Addressing code to any extent, and does so often by prefixing the address strings with 'ADDR:' because the test profiles are all running set to use the old BindingURL syntax. As a result it would seem we ultimately arent testing the precise execution paths for many operations users will undertake at all. This is one of the biggest obstacles I had when testing the new address based implementation. Switching the default will create many test failures that is impossible to handle on my own. Also switching the default is not a good solution either as we still support the older binding URL mechanism as well. The addressing scheme actually exercised code paths in a certain way that it highlighted several race conditions, a few dead locks and many other errors that were there in the code base for a long time. Therefore it would have been nice had I been able to catch these issues using our test suites. Ex issues in durable
[jira] Created: (QPID-3147) Misconfigured tracing/logging can lead to hung threads in logging stack
Misconfigured tracing/logging can lead to hung threads in logging stack --- Key: QPID-3147 URL: https://issues.apache.org/jira/browse/QPID-3147 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.10 Environment: Fedora 14 32-bit Reporter: Pete MacKinnon Priority: Minor Given the following trace and logging environment variable mix-up like this: QPID_TRACE=debug+ QPID_LOG_ENABLE= A C++ client that embeds the Qpid runtime can get hung although it has recognized the misconfiguration. #0 0x00555416 in __kernel_vsyscall () #1 0x00f49367 in syscall () at ../sysdeps/unix/sysv/linux/i386/syscall.S:30 #2 0x002bbfca in __cxxabiv1::__cxa_guard_acquire (g=0x2171ea0) at ../../../../libstdc++-v3/libsupc++/guard.cc:293 #3 0x020ca3b8 in instance () at /usr/include/boost/pool/detail/singleton.hpp:83 #4 qpid::log::Logger::instance () at qpid/log/Logger.cpp:47 #5 0x020cd324 in qpid::log::Statement::Initializer::Initializer ( this=0x2171b88, s=...) at qpid/log/Statement.cpp:61 #6 0x02075b6c in qpid::Exception::Exception (this=0x880b370, msg= Error in environment variables: in option 'trace': invalid bool value\n) at qpid/Exception.cpp:31 #7 0x0208095d in Exception (this=0xbf8d0df0, argc=0, argv=0x0, configFile=, allowUnknown=false) at ../include/qpid/Options.h:210 #8 qpid::Options::parse (this=0xbf8d0df0, argc=0, argv=0x0, configFile=, allowUnknown=false) at qpid/Options.cpp:352 #9 0x020c9c57 in qpid::log::Logger::Logger (this=0x2171ec0) at qpid/log/Logger.cpp:55 #10 0x020ca330 in instance () at /usr/include/boost/pool/detail/singleton.hpp:83 #11 object_creator () at /usr/include/boost/pool/detail/singleton.hpp:66 #12 __static_initialization_and_destruction_0 () at /usr/include/boost/pool/detail/singleton.hpp:95 #13 global constructors keyed to Logger.cpp(void) () at qpid/log/Logger.cpp:156 #14 0x020ebc6d in __do_global_ctors_aux () from /usr/lib/libqpidcommon.so.2 #15 0x01fc2a84 in _init () from /usr/lib/libqpidcommon.so.2 #16 0x004f68fc in call_init (l=value optimized out, argc=3, argv=0xbf8d1634, env=0x87feb58) at dl-init.c:68 #17 0x004f6a19 in _dl_init (main_map=value optimized out, argc=3, argv=0xbf8d1634, env=0x87feb58) at dl-init.c:132 #18 0x004fa74f in dl_open_worker (a=0xbf8d10d0) at dl-open.c:464 #19 0x004f6786 in _dl_catch_error (objname=0xbf8d10f8, errstring=0xbf8d10f4, mallocedp=0xbf8d10ff, operate=0x4fa3b0 dl_open_worker, args=0xbf8d10d0) at dl-error.c:178 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-3146) Windows cpp examples: exe files go to different directories based on configuration and platform
[ https://issues.apache.org/jira/browse/QPID-3146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13007050#comment-13007050 ] Steve Huston commented on QPID-3146: I think this is ok. Windows cpp examples: exe files go to different directories based on configuration and platform --- Key: QPID-3146 URL: https://issues.apache.org/jira/browse/QPID-3146 Project: Qpid Issue Type: Improvement Reporter: Chuck Rolke The project files for the cpp examples use inconsistent path specs for the output. For instance, messaging client uses: messaging\messaging_client.vcproj: OutputDirectory=. messaging\messaging_client.vcproj: OutputDirectory=Release messaging\messaging_client.vcproj: OutputDirectory=$(PlatformName)\$(ConfigurationName) messaging\messaging_client.vcproj: OutputDirectory=$(PlatformName)\$(ConfigurationName) where $(PlatformName) is win32 or x64, and $(ConfigurationName) is debug or release. In practice this translates to the file client.exe landing in messaging\ messaging\Release\ messaging\x64\debug\ messaging\x64\release\ I propose to modify the vcproj files so that the output directory in all cases is $(PlatformName)\$(ConfigurationName). In the vcproj file the OutputDirectory value is always $(PlatformName)\$(ConfigurationName). To find a specific built executable you then need to navigate to cpp\examples\messaging, then to win32 or x64, and then to debug or release. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-3144) qpidd --check does not work with info logging and --log-to-stdout=yes
[ https://issues.apache.org/jira/browse/QPID-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13007152#comment-13007152 ] Alan Conway commented on QPID-3144: --- Those log statements are in a precarious position, during plugin loading before things have been properly initialized. IMO they have little to no value and should be removed given that they're causing useful functionality (qpidd --check) to fail in some situations. If we want to log an init message for plugins it should be at plugin _initialization_ (not loading) when things are better set up. Most plugins have their own init logging already, it would be easy to do a global plugin foo initialized message as well. qpidd --check does not work with info logging and --log-to-stdout=yes - Key: QPID-3144 URL: https://issues.apache.org/jira/browse/QPID-3144 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.9 Reporter: Alan Conway Assignee: Alan Conway Priority: Minor Fix For: 0.10 qpidd --check is supposed to print the PID of a running qpidd --daemon, for use in scripts and the like. However with info logging and log-to-stdout enabled this does not work because log messages of the form: 2011-03-14 16:21:05 info Loaded Module: /usr/lib64/qpid/daemon/cluster.so precede the port number. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Request to include QPID-3143 in the 0.10 release
On Tue, 15 Mar 2011, Robbie Gemmell wrote: On 15 March 2011 17:33, Rajith Attapattu rajit...@gmail.com wrote: On Tue, Mar 15, 2011 at 1:24 PM, Robert Godfrey rob.j.godf...@gmail.comwrote: I see both side here, I think the fundamental issue for me is that I hadn't previously picked up that when the change to the default addressing syntax was changed in the 0.8 release, the tests were made to explicitly run with the Binding URL as the default. As such we are not exposing the default that we are giving to users when we run the tests - thus the expected normal code path is not being exercised in our tests other than in the one test that Robbie highlighted (and this uses the explicit ADDR: syntax). As such I don't feel like simply running the tests gives me the confidence that this change will not have unforseen consequences. In truth I actually now feel quite nervous about what we did in 0.8. I strongly feel that we should update the tests to use the default (which is now ADDR) syntax - changing any test where the BindingURL is implicitly expected. Given that this is a change rather than a bug fix, the fact that we are supposed to be in code freeze in preparation for release, and that I don't have confidence that we are adequately testing the default behaviour using the standard tests - I don't feel that it is appropriate to include in 0.10. I actually consider this a bug as I didn't really implement what I should have in the first place. The current behaviour is neither backwards compatible nor correct as per the JMS spec. As for your comments about the tests, I fully agree with you and have said the same in my response to Robbie with some examples. But as I mentioned, that risk is **already there in 0.10** and this commit is not adding anything to it. Rajith In my mind this is a 'feature' change rather than bug fix as the patch would alter a behaviour of the client that was, correctly or otherwise, long since put there deliberately and which you preserved deliberately. You are correct that there is existing risk already in 0.10, however this is an additional change which would clearly introduce an additional risk of unforseen effects in its own right versus not including it. Not having enough confidence in the existing situation is no reason to throw caustion to the wind. Robbie Thanks, Rob, Robbie, and Rajith, for the discussion. Applying the no regressions, even prospective ones rule, I oppose this change for 0.10. To my impression, it blurs the feature/bug distinction, and I personally accept it as a defect. That doesn't mean, however, that we should accept it for 0.10. Since the fix also constitutes an important behavior change, and since it poses a real risk of introducing new regressions, I think it should wait for 0.12. Justin - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
QPID-3143 in the 0.10 release
All my replies to the thread had bounced for being identified as spam :D Anyways the summary of those emails that didn't make it was to say that I agreed with Rob's comments. i.e this change is not of high value to be included at this stage of the release, hence withdrawing my request. I had notified this via private email to both Robbie and Rob after repeated attempts to get through to the list. Regards, Rajith
[jira] Resolved: (QPID-3106) QueueReceiver and TopicSubscriber does not work with new addressing
[ https://issues.apache.org/jira/browse/QPID-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajith Attapattu resolved QPID-3106. Resolution: Fixed Fix Version/s: (was: 0.9) 0.10 Fixed along with a test case. QueueReceiver and TopicSubscriber does not work with new addressing --- Key: QPID-3106 URL: https://issues.apache.org/jira/browse/QPID-3106 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.8 Reporter: Rajith Attapattu Assignee: Rajith Attapattu Fix For: 0.10 The QueueReceiver and TopicSubscriber interfaces are part of JMS. However this part of the API cannot be used with Destinations defined using the new addressing scheme. This is due to the code trying to check if the the Queue implementation is of type AMQQueue and Topic implementation is of type AMQTopic. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-3109) Java client needs to implement the Delete option in address string
[
https://issues.apache.org/jira/browse/QPID-3109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajith Attapattu resolved QPID-3109.
Resolution: Fixed
Fix Version/s: (was: 0.9)
0.10
The feature is implemented along with test cases.
Java client needs to implement the Delete option in address string
--
Key: QPID-3109
URL: https://issues.apache.org/jira/browse/QPID-3109
Project: Qpid
Issue Type: Improvement
Components: Java Client
Affects Versions: 0.8
Reporter: Rajith Attapattu
Assignee: Rajith Attapattu
Priority: Minor
Fix For: 0.10
The address syntax defines a delete option with 4 possible values - {always,
receiver, sender, never}.
The default value is 'never'.
if delete = 'always' or delete = 'sender', then when a sender is closed it
should delete the queue.
if delete = 'always' or delete = 'receiver', then when a receiver is closed
it should delete the queue.
Please note that the client will delete the queue irrespective of whether
there are consumers on the queue or not.
Also it will not take into account whether the queue is empty or not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-3099) Java qpid-client ignores hostnames containing underscores
[ https://issues.apache.org/jira/browse/QPID-3099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajith Attapattu resolved QPID-3099. Resolution: Fixed Fix Version/s: (was: 0.9) 0.10 Fixed along with a test case. Java qpid-client ignores hostnames containing underscores - Key: QPID-3099 URL: https://issues.apache.org/jira/browse/QPID-3099 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.5, 0.6, 0.8 Reporter: Rajith Attapattu Assignee: Rajith Attapattu Priority: Minor Fix For: 0.10 When defining a connection URL listing a broker that has an underscore the hostname results in the broker host being evaluated to localhost rather than the intended host. e.g. amqp://guest:guest@clientid/test?brokerlist='tcp://under_score:5672' amqp://guest:guest@clientid/test?brokerlist='tcp://under_score' -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-3050) JMS client producer option -Dsync_publish=persistent has no effect
[ https://issues.apache.org/jira/browse/QPID-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajith Attapattu resolved QPID-3050. Resolution: Fixed Fix Version/s: (was: 0.9) 0.10 Fixed by correcting the copy paste error. Tested manually as it's not yet possible to add an automated test for this. JMS client producer option -Dsync_publish=persistent has no effect -- Key: QPID-3050 URL: https://issues.apache.org/jira/browse/QPID-3050 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.6, 0.8 Reporter: Rajith Attapattu Assignee: Rajith Attapattu Priority: Minor Fix For: 0.10 The sync_publish system property is not read properly in the code. In AMQConnection the correct name is not used when retrieving this system property. The corresponding connection URL parameter does work. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-3098) Java client does not support java.util.UUID in a Map message
[ https://issues.apache.org/jira/browse/QPID-3098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajith Attapattu resolved QPID-3098. Resolution: Fixed Fix Version/s: (was: 0.9) 0.10 Fixed along with test cases. Java client does not support java.util.UUID in a Map message Key: QPID-3098 URL: https://issues.apache.org/jira/browse/QPID-3098 Project: Qpid Issue Type: Improvement Components: Java Client Affects Versions: 0.6 Reporter: Rajith Attapattu Assignee: Rajith Attapattu Priority: Minor Fix For: 0.10 The setObject method implementation in javax.jms.MapMessage currently allows java.util.List and java.util.Map objects to be inserted in addition to the objects required by the JMS specifications. There have been interest in allowing a UUID (a supported data type in AMQP 0-10) to be inserted into the map message. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-3043) If a new session is created during failover, but before 'resume' is completed, the new session gets reattached again.
[ https://issues.apache.org/jira/browse/QPID-3043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajith Attapattu resolved QPID-3043. Resolution: Fixed Fix Version/s: (was: Future) 0.10 The commit has been reviewed and was tested manually as part of a larger issue. If a new session is created during failover, but before 'resume' is completed, the new session gets reattached again. - Key: QPID-3043 URL: https://issues.apache.org/jira/browse/QPID-3043 Project: Qpid Issue Type: Bug Affects Versions: 0.6, 0.7, 0.8 Reporter: Rajith Attapattu Assignee: Rajith Attapattu Fix For: 0.10 This bug was discovered while investigating QPID-2994 There exists a race condition, where if a session is created (after the connection is setup and is marked OPEN) but before the resume method (in Connection.java) is called, it results in the new session being reattached again. This could result in unnecessary duplication of messages. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-3042) Session.attach could be sent before the connection is open.
[ https://issues.apache.org/jira/browse/QPID-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajith Attapattu resolved QPID-3042. Resolution: Fixed Fix Version/s: (was: Future) 0.10 Tested as part of QPID-2994 There is a test harness under the testkit module to test transactions during failover which should adequately cover this issue. Session.attach could be sent before the connection is open. --- Key: QPID-3042 URL: https://issues.apache.org/jira/browse/QPID-3042 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.6, 0.7, 0.8 Reporter: Rajith Attapattu Assignee: Rajith Attapattu Fix For: 0.10 This bug was discovered while investigating QPID-2994 This bug also caused QPID-3033 There exist a race condition where an application could create a new session (recreating due to an exception or a completely new session in the midst of failover) before the connection is open. This results in session attach being sent before the connection negotiation is completed. All though the connect method and the createSession method in Connection.java contends for the same lock, the connect method which acquires it early, will releases the lock when it waits (until the connection achieves OPEN state) and the createSession method waiting on the lock will get it and continue. Usually this only becomes an issue during failover, as during the initial connection creation, the application thread that creates the connection will wait until the connect method returns before it creates a session. However If an application tries to create a connection in one thread and several other threads try to create sessions from that connection, and if those threads don't coordinate properly to check if the connection is opened, then this same race condition is present. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-3019) Exception not reported properly when creating a Producer with an invalid destination
[ https://issues.apache.org/jira/browse/QPID-3019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajith Attapattu resolved QPID-3019. Resolution: Fixed Fix Version/s: (was: 0.9) 0.10 Fixed along with a test case. Exception not reported properly when creating a Producer with an invalid destination Key: QPID-3019 URL: https://issues.apache.org/jira/browse/QPID-3019 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.8 Reporter: Rajith Attapattu Assignee: Rajith Attapattu Fix For: 0.10 When creating a message producer with an invalid destination an exception is not thrown. When the send method on the producer (created with an invalid destination) is invoked it results in exceptions. Exception in thread main java.lang.NullPointerException at org.apache.qpid.client.BasicMessageProducer_0_10.sendMessage(BasicMessageProducer_0_10.java:166) at org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:490) at org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:445) at org.apache.qpid.client.BasicMessageProducer.send(BasicMessageProducer.java:283) at org.apache.qpid.example.Spout.init(Spout.java:98) at org.apache.qpid.example.Spout.main(Spout.java:146) Therefore it's important an exception to be thrown at the time of creating a producer (or consumer) when an invalid destination is supplied. (Note. the consumer creation code path does throw an exception as expected.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-2994) transactions atomicity violated by 'transparent' failover
[ https://issues.apache.org/jira/browse/QPID-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajith Attapattu resolved QPID-2994. Resolution: Fixed Fix Version/s: (was: Future) 0.10 Fixed along with related issues - QPID-3042 QPID-3043. Tested manually and added a test case to the test harness in testkit.py transactions atomicity violated by 'transparent' failover - Key: QPID-2994 URL: https://issues.apache.org/jira/browse/QPID-2994 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.6, 0.7, 0.8 Reporter: Rajith Attapattu Assignee: Rajith Attapattu Fix For: 0.10 Attachments: QPID-2994.patch The messages published within a batch at the point the connection failsover appear to be replayed outside of any transaction. Steps to Reproduce: 1. start transactional session on failover enabled connection 2. send batches of messages in transactions 3. kill the cluster node the client is connected to, to trigger failover mid transaction This happens due to the lower layer replaying unacked messages upon resuming the connection. Message replay should not happen on a transacted session as there is no benefit of doing so. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Request to include QPID-3143 in the 0.10 release
On 14 Mar 2011, at 21:41, Rajith Attapattu wrote:
On Mon, Mar 14, 2011 at 5:33 PM, Andrew Kennedy
andrewinternatio...@gmail.com wrote:
Ok,
From line 1216 of the latest AMQSession.java we have:
if (queueName.indexOf('/') == -1 queueName.indexOf(';') == -1)
{
DestSyntax syntax = AMQDestination.getDestType(queueName);
if (syntax == AMQDestination.DestSyntax.BURL)
{
// For testing we may want to use the prefix
return new AMQQueue(getDefaultQueueExchangeName(),
new AMQShortString(AMQDestination.stripSyntaxPrefix
(queueName)));
}
else
{
AMQQueue queue = new AMQQueue(queueName);
return queue;
}
}
else
{
return new AMQQueue(queueName);
}
}
Rajith,
I've had time to catch up on the complete session.createQueue
discussion, and noticed you aren't pushing this for 0.10 inclusion
anymore. I agree with Rob et al and yourself that we aren't testing
things correctly. As I understood things, the (current) incorrect
behaviour was added here:
Revision 964984
http://svn.apache.org/viewvc/qpid/trunk/qpid/java/client/src/main/
java/org/apache/qpid/client/AMQSession.java?
annotate=964984diff_format=hpathrev=1081460
Modified Fri Jul 16 23:50:13 2010 UTC (7 months, 4 weeks ago) by rajith
And was therefore present in 0.8, which I had not realised before. I
think making the change is the right thing to do, but only once we
have updated the default test profile and the tests accordingly. If
the behavioural change had been introduced *post* 0.8, I think there
would be a stronger case for inclusion.
We probably need to create profiles like this {broker}-{addressing
format}-{amqp version}:
vm-addr-0.10 (default), vm-burl-0.10, java-addr-0.10, java-
burl-0.10, cpp-addr-0.10, etc.
Or, we could change the test profile mechanism, so you can specify
something like -Dprofiles=java,burl,0.10,mina, with (sensible)
combinations of sub-profiles being valid for the system tests. The
default set should still be something like vm,addr,0.10 though.
This is (fairly) easy with Maven ;)
[...] should we really not just change this to simply return new
AMQQueue(queueName); and then leave everything to the addressing
syntax logic in AMQBindingURL.java and friends instead? It looks
like it should just work, but I haven't tested it. Oh, right, we
get the defaultQueueExchangeName from the *connection* URL, I see.
Well, that's probably more difficult...
The reason is that the old implementation uses the amq.direct as
the exchange name (which is what returned by
defaultQueueExchangeName.)
The addressing syntax implementation just uses the default exchange
(or the nameless exchange) when dealing with queues.
So, with BURL syntax, you can override the default exchange name on
the connection URL. But, using ADDR syntax for the destination, there
is no way of overriding the default exchange name, then, even if we
change it on the connection URL? Is this right? Or, would you be also
using an ADDR type URL for the connection in that case?
Just wanted to make it obvious in the code. Perhaps I should add a
comment there as well ?
Yes, good idea.
Andrew.
--
-- andrew d kennedy ? do not fold, bend, spindle, or mutilate ;
-- http://grkvlt.blogspot.com/ ? edinburgh : +44 7582 293 255 ;
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
