Re: Review Request: Abstraction for SASL server role that is not tied to 0-10
On Nov. 2, 2012, 6:57 a.m., mick goulish wrote: /trunk/qpid/cpp/src/qpid/NullSaslServer.cpp, line 41 https://reviews.apache.org/r/7565/diff/1/?file=176223#file176223line41 I feel kind of funny about throwing for an error in an input to the system -- but definitely should log it.info? error? Committed a minor adjustment to log this and return the failure code. - Gordon --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7565/#review13029 --- On Oct. 12, 2012, 4:47 p.m., Gordon Sim wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7565/ --- (Updated Oct. 12, 2012, 4:47 p.m.) Review request for qpid, michael goulish, Ted Ross, and mick goulish. Description --- The current broker::SaslAuthenticator mixes 0-10 protocol handshaking with the sasl interactions. This patch adds a cleaner abstraction of the server role in SASL along side that already in place for the client. This is then used in the 1.0 SASL implementation. (Note this patch assumes and partially includes https://reviews.apache.org/r/7562/ as I could not find an easy way to separate out commits in git into review-board compatible patches). This addresses bug QPID-4368. https://issues.apache.org/jira/browse/QPID-4368 Diffs - /trunk/qpid/cpp/src/CMakeLists.txt 1397295 /trunk/qpid/cpp/src/Makefile.am 1397295 /trunk/qpid/cpp/src/qpid/NullSaslServer.h PRE-CREATION /trunk/qpid/cpp/src/qpid/NullSaslServer.cpp PRE-CREATION /trunk/qpid/cpp/src/qpid/Sasl.h 1397295 /trunk/qpid/cpp/src/qpid/SaslFactory.h 1397295 /trunk/qpid/cpp/src/qpid/SaslFactory.cpp 1397295 /trunk/qpid/cpp/src/qpid/SaslServer.h PRE-CREATION Diff: https://reviews.apache.org/r/7565/diff/ Testing --- Thanks, Gordon Sim
Using script-native drivers for Proton messenger bindings
One of the problems we've had for a long time with wrapped bindings is the mismatch of threading models. For example, a Ruby program using an extension module written in C/C++ will hang if a call into the extension blocks. This is because the extension uses pthreads and the host program uses greenthreads (i.e. some layered threading mechanism in the scripting language). This is also an issue for Python (and probably every other scripting language). The proper solution for proton/messenger (which necessarily has a few blocking calls) is to provide (or allow the developer to provide) a driver written in the scripting language using the same threading library that their program uses. The proton code structure allows for such a strategy, but the packaging does not. I think that the proton project should make the necessary adjustments to encourage developers to contribute native drivers for Ruby, Python-eventlet, etc. I'm interested in others' thoughts on this and what would be necessary to make this happen. -Ted - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-4428) HA add UUID tag to avoid using an out of date queue.
[ https://issues.apache.org/jira/browse/QPID-4428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved QPID-4428. --- Resolution: Fixed Fix Version/s: 0.19 Fixed on trunk: r1409241 | QPID-4428: HA add UUID tag to avoid using an out of date queue/exchange. HA add UUID tag to avoid using an out of date queue. Key: QPID-4428 URL: https://issues.apache.org/jira/browse/QPID-4428 Project: Qpid Issue Type: Bug Components: C++ Clustering Affects Versions: 0.19 Reporter: Alan Conway Assignee: Alan Conway Fix For: 0.19 Here's the scenario: we have a cluster with primary A and backups B and C. There is a queue Q that is replicated to both. Now A dies and B takes over as primary. Before C has connected to B, a client destroys Q and creates a new queue with the same name, Q. When C does connect it sees a queue named Q and mistakenly assumes it is the same queue as it's own Q - so it has an incorrect replica of Q. The same scenario applies to exchanges. The fix is to tag queues and exchanges with a UUID, so backups can identify that the queue has changed even if the name is the same. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Using script-native drivers for Proton messenger bindings
On Wed, Nov 14, 2012 at 10:54:45AM -0500, Ted Ross wrote: One of the problems we've had for a long time with wrapped bindings is the mismatch of threading models. For example, a Ruby program using an extension module written in C/C++ will hang if a call into the extension blocks. This is because the extension uses pthreads and the host program uses greenthreads (i.e. some layered threading mechanism in the scripting language). This is also an issue for Python (and probably every other scripting language). The proper solution for proton/messenger (which necessarily has a few blocking calls) is to provide (or allow the developer to provide) a driver written in the scripting language using the same threading library that their program uses. The proton code structure allows for such a strategy, but the packaging does not. I think that the proton project should make the necessary adjustments to encourage developers to contribute native drivers for Ruby, Python-eventlet, etc. I'm interested in others' thoughts on this and what would be necessary to make this happen. I'm not sure I follow what is meant by the packaging does not. Can you be more specific there? -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgp5ujoUfSC3b.pgp Description: PGP signature
Re: 0.20 release update - beta postponed, alpha 2 available
On 11/02/2012 12:28 AM, Justin Ross wrote: Hi, folks. I have updated our schedule on the release page to reflect the previously discussed postponement. The 0.20 beta date is now November 14th. If possible, I'd like a little more time to wrap up the AMQP 1.0 work for c++ for the 0.20 release (even another day or so would make a big difference). I'm happy to make the changes on a release branch if people are keen to get the trunk unfrozen again. The changes would be confined to the 1.0 implementation code (which incidentally was broken by QPID-4272, though I have fixes ready for that). - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4424) C++ Broker on Windows - Assertion Failed: !dispatcher - PollableQueue.h line 136
[
https://issues.apache.org/jira/browse/QPID-4424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher updated QPID-4424:
--
Priority: Blocker (was: Major)
C++ Broker on Windows - Assertion Failed: !dispatcher - PollableQueue.h line
136
Key: QPID-4424
URL: https://issues.apache.org/jira/browse/QPID-4424
Project: Qpid
Issue Type: Bug
Components: C++ Broker
Affects Versions: 0.18
Environment: Windows Server 2008 R2 64-bit system
Visual Studio 2010 32-bit executable
Reporter: Chuck Rolke
Priority: Blocker
Start broker with 'qpidd --auth no --no-data-dir'.
Sit for 15 or so seconds. No external connections from clients. No cluster.
Assert happens.
Stack at assert time:
msvcr100d.dll!_NMSG_WRITE(int rterrnum=10) Line 217C
msvcr100d.dll!abort() Line 61 + 0x7 bytes C
msvcr100d.dll!_wassert(const wchar_t * expr=0x5ff25504, const wchar_t *
filename=0x5ff25480, unsigned int lineno=136) Line 153 C
qpidbrokerd.dll!qpid::sys::PollableQueuestd::pairboost::shared_ptrqpid::broker::Exchange,qpid::broker::Message
::dispatch(qpid::sys::PollableCondition cond={...}) Line 136 + 0x36
bytes C++
qpidbrokerd.dll!boost::_mfi::mf1void,qpid::sys::PollableQueuestd::pairboost::shared_ptrqpid::broker::Exchange,qpid::broker::Message
,qpid::sys::PollableCondition
::operator()(qpid::sys::PollableQueuestd::pairboost::shared_ptrqpid::broker::Exchange,qpid::broker::Message
* p=0x00c72b80, qpid::sys::PollableCondition a1={...}) Line 165 + 0x10
bytes C++
qpidbrokerd.dll!boost::_bi::list2boost::_bi::valueqpid::sys::PollableQueuestd::pairboost::shared_ptrqpid::broker::Exchange,qpid::broker::Message
*,boost::arg1
::operator()boost::_mfi::mf1void,qpid::sys::PollableQueuestd::pairboost::shared_ptrqpid::broker::Exchange,qpid::broker::Message
,qpid::sys::PollableCondition
,boost::_bi::list1qpid::sys::PollableCondition (boost::_bi::typevoid
__formal={...},
boost::_mfi::mf1void,qpid::sys::PollableQueuestd::pairboost::shared_ptrqpid::broker::Exchange,qpid::broker::Message
,qpid::sys::PollableCondition f={...},
boost::_bi::list1qpid::sys::PollableCondition a={...},
boost::_bi::typevoid __formal={...}) Line 314C++
qpidbrokerd.dll!boost::_bi::bind_tvoid,boost::_mfi::mf1void,qpid::sys::PollableQueuestd::pairboost::shared_ptrqpid::broker::Exchange,qpid::broker::Message
,qpid::sys::PollableCondition
,boost::_bi::list2boost::_bi::valueqpid::sys::PollableQueuestd::pairboost::shared_ptrqpid::broker::Exchange,qpid::broker::Message
*,boost::arg1
::operator()qpid::sys::PollableCondition(qpid::sys::PollableCondition
a1={...}) Line 33 C++
qpidbrokerd.dll!boost::detail::function::void_function_obj_invoker1boost::_bi::bind_tvoid,boost::_mfi::mf1void,qpid::sys::PollableQueuestd::pairboost::shared_ptrqpid::broker::Exchange,qpid::broker::Message
,qpid::sys::PollableCondition
,boost::_bi::list2boost::_bi::valueqpid::sys::PollableQueuestd::pairboost::shared_ptrqpid::broker::Exchange,qpid::broker::Message
*,boost::arg1 ,void,qpid::sys::PollableCondition
::invoke(boost::detail::function::function_buffer function_obj_ptr={...},
qpid::sys::PollableCondition a0={...}) Line 154 C++
qpidcommond.dll!boost::function1void,qpid::sys::PollableCondition
::operator()(qpid::sys::PollableCondition a0={...}) Line 760 + 0x1a
bytes C++
qpidcommond.dll!qpid::sys::PollableConditionPrivate::dispatch(qpid::sys::windows::AsynchIoResult
* result=0x00cad6e0) Line 81 C++
qpidcommond.dll!boost::_mfi::mf1void,qpid::sys::PollableConditionPrivate,qpid::sys::windows::AsynchIoResult
*::operator()(qpid::sys::PollableConditionPrivate * p=0x00c72cd0,
qpid::sys::windows::AsynchIoResult * a1=0x00cad6e0) Line 165 + 0x10 bytes
C++
qpidcommond.dll!boost::_bi::list2boost::_bi::valueqpid::sys::PollableConditionPrivate
*,boost::arg1
::operator()boost::_mfi::mf1void,qpid::sys::PollableConditionPrivate,qpid::sys::windows::AsynchIoResult
*,boost::_bi::list1qpid::sys::windows::AsynchIoResult *
(boost::_bi::typevoid __formal={...},
boost::_mfi::mf1void,qpid::sys::PollableConditionPrivate,qpid::sys::windows::AsynchIoResult
* f={...}, boost::_bi::list1qpid::sys::windows::AsynchIoResult *
a={...}, boost::_bi::typevoid __formal={...}) Line 314 C++
qpidcommond.dll!boost::_bi::bind_tvoid,boost::_mfi::mf1void,qpid::sys::PollableConditionPrivate,qpid::sys::windows::AsynchIoResult
*,boost::_bi::list2boost::_bi::valueqpid::sys::PollableConditionPrivate
*,boost::arg1 ::operator()qpid::sys::windows::AsynchIoResult
*(qpid::sys::windows::AsynchIoResult * a1=0x00cad6e0) Line 33 C++
[jira] [Commented] (QPID-4424) C++ Broker on Windows - Assertion Failed: !dispatcher - PollableQueue.h line 136
[
https://issues.apache.org/jira/browse/QPID-4424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497277#comment-13497277
]
Andrew Stitcher commented on QPID-4424:
---
I think this regression was caused by r1404590.
A work around for this bug is to run the broker without management (-m0)
C++ Broker on Windows - Assertion Failed: !dispatcher - PollableQueue.h line
136
Key: QPID-4424
URL: https://issues.apache.org/jira/browse/QPID-4424
Project: Qpid
Issue Type: Bug
Components: C++ Broker
Affects Versions: 0.18
Environment: Windows Server 2008 R2 64-bit system
Visual Studio 2010 32-bit executable
Reporter: Chuck Rolke
Priority: Blocker
Start broker with 'qpidd --auth no --no-data-dir'.
Sit for 15 or so seconds. No external connections from clients. No cluster.
Assert happens.
Stack at assert time:
msvcr100d.dll!_NMSG_WRITE(int rterrnum=10) Line 217C
msvcr100d.dll!abort() Line 61 + 0x7 bytes C
msvcr100d.dll!_wassert(const wchar_t * expr=0x5ff25504, const wchar_t *
filename=0x5ff25480, unsigned int lineno=136) Line 153 C
qpidbrokerd.dll!qpid::sys::PollableQueuestd::pairboost::shared_ptrqpid::broker::Exchange,qpid::broker::Message
::dispatch(qpid::sys::PollableCondition cond={...}) Line 136 + 0x36
bytes C++
qpidbrokerd.dll!boost::_mfi::mf1void,qpid::sys::PollableQueuestd::pairboost::shared_ptrqpid::broker::Exchange,qpid::broker::Message
,qpid::sys::PollableCondition
::operator()(qpid::sys::PollableQueuestd::pairboost::shared_ptrqpid::broker::Exchange,qpid::broker::Message
* p=0x00c72b80, qpid::sys::PollableCondition a1={...}) Line 165 + 0x10
bytes C++
qpidbrokerd.dll!boost::_bi::list2boost::_bi::valueqpid::sys::PollableQueuestd::pairboost::shared_ptrqpid::broker::Exchange,qpid::broker::Message
*,boost::arg1
::operator()boost::_mfi::mf1void,qpid::sys::PollableQueuestd::pairboost::shared_ptrqpid::broker::Exchange,qpid::broker::Message
,qpid::sys::PollableCondition
,boost::_bi::list1qpid::sys::PollableCondition (boost::_bi::typevoid
__formal={...},
boost::_mfi::mf1void,qpid::sys::PollableQueuestd::pairboost::shared_ptrqpid::broker::Exchange,qpid::broker::Message
,qpid::sys::PollableCondition f={...},
boost::_bi::list1qpid::sys::PollableCondition a={...},
boost::_bi::typevoid __formal={...}) Line 314C++
qpidbrokerd.dll!boost::_bi::bind_tvoid,boost::_mfi::mf1void,qpid::sys::PollableQueuestd::pairboost::shared_ptrqpid::broker::Exchange,qpid::broker::Message
,qpid::sys::PollableCondition
,boost::_bi::list2boost::_bi::valueqpid::sys::PollableQueuestd::pairboost::shared_ptrqpid::broker::Exchange,qpid::broker::Message
*,boost::arg1
::operator()qpid::sys::PollableCondition(qpid::sys::PollableCondition
a1={...}) Line 33 C++
qpidbrokerd.dll!boost::detail::function::void_function_obj_invoker1boost::_bi::bind_tvoid,boost::_mfi::mf1void,qpid::sys::PollableQueuestd::pairboost::shared_ptrqpid::broker::Exchange,qpid::broker::Message
,qpid::sys::PollableCondition
,boost::_bi::list2boost::_bi::valueqpid::sys::PollableQueuestd::pairboost::shared_ptrqpid::broker::Exchange,qpid::broker::Message
*,boost::arg1 ,void,qpid::sys::PollableCondition
::invoke(boost::detail::function::function_buffer function_obj_ptr={...},
qpid::sys::PollableCondition a0={...}) Line 154 C++
qpidcommond.dll!boost::function1void,qpid::sys::PollableCondition
::operator()(qpid::sys::PollableCondition a0={...}) Line 760 + 0x1a
bytes C++
qpidcommond.dll!qpid::sys::PollableConditionPrivate::dispatch(qpid::sys::windows::AsynchIoResult
* result=0x00cad6e0) Line 81 C++
qpidcommond.dll!boost::_mfi::mf1void,qpid::sys::PollableConditionPrivate,qpid::sys::windows::AsynchIoResult
*::operator()(qpid::sys::PollableConditionPrivate * p=0x00c72cd0,
qpid::sys::windows::AsynchIoResult * a1=0x00cad6e0) Line 165 + 0x10 bytes
C++
qpidcommond.dll!boost::_bi::list2boost::_bi::valueqpid::sys::PollableConditionPrivate
*,boost::arg1
::operator()boost::_mfi::mf1void,qpid::sys::PollableConditionPrivate,qpid::sys::windows::AsynchIoResult
*,boost::_bi::list1qpid::sys::windows::AsynchIoResult *
(boost::_bi::typevoid __formal={...},
boost::_mfi::mf1void,qpid::sys::PollableConditionPrivate,qpid::sys::windows::AsynchIoResult
* f={...}, boost::_bi::list1qpid::sys::windows::AsynchIoResult *
a={...}, boost::_bi::typevoid __formal={...}) Line 314 C++
qpidcommond.dll!boost::_bi::bind_tvoid,boost::_mfi::mf1void,qpid::sys::PollableConditionPrivate,qpid::sys::windows::AsynchIoResult
QPID-4424: C++ Broker on Windows - Assertion Failed
I'd just like to point out this bug because I think it hasn't got any attention yet, but is a serious regression that crashes a windows broker. As far as I can tell it was caused by r1404590 - Git SHA 00935fcbf0cc (QPID-4394: HA QMF events out of order). This is the first time, as far as I can tell, that the Windows PollableQueue code has been used at all, so although the code compiles it was never used before and it fails. Andrew - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Review Request: proton-c: support for AMQP 1.0 connection idle timeout negotiation and keepalives
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8021/#review13432 --- Ship it! Ship It! - Rafael Schloming On Nov. 13, 2012, 5:02 p.m., Kenneth Giusti wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8021/ --- (Updated Nov. 13, 2012, 5:02 p.m.) Review request for qpid, Andrew Stitcher and Rafael Schloming. Description --- Attached is an attempt at adding Connection idle-time-out support to Proton-c, as defined by the AMQP 1.0 spec. Notes: 1) Allows configuration of the AMQP Connection idle timeout locally, and support for receiving the remote's configured idle timeout. 2) Will send periodic keepalive (empty) frames to satisfy remote's idle requirements, if needed. 3) Will close the connection if remote violates the locally configured idle deadline This addresses bug proton-111. https://issues.apache.org/jira/browse/proton-111 Diffs - /proton/trunk/proton-c/CMakeLists.txt 1408810 /proton/trunk/proton-c/bindings/python/proton.py 1408810 /proton/trunk/proton-c/include/proton/driver.h 1408810 /proton/trunk/proton-c/include/proton/engine.h 1408810 /proton/trunk/proton-c/include/proton/types.h 1408810 /proton/trunk/proton-c/src/dispatcher/dispatcher.h 1408810 /proton/trunk/proton-c/src/dispatcher/dispatcher.c 1408810 /proton/trunk/proton-c/src/driver.c 1408810 /proton/trunk/proton-c/src/engine/engine-internal.h 1408810 /proton/trunk/proton-c/src/engine/engine.c 1408810 /proton/trunk/proton-c/src/messenger.c 1408810 /proton/trunk/proton-c/src/util.h 1408810 /proton/trunk/proton-c/src/util.c 1408810 /proton/trunk/proton-j/src/main/scripts/proton.py 1408810 /proton/trunk/tests/proton_tests/engine.py 1408810 Diff: https://reviews.apache.org/r/8021/diff/ Testing --- Added an engine test case to verify that the timers are tracked, and the action when timers fire, but I need to add a test at the driver level, too. Thanks, Kenneth Giusti
Re: QPID-4424: C++ Broker on Windows - Assertion Failed
Is anyone looking at this? If not, I'll try to have a look later today. On 11/14/12 12:50 PM, Andrew Stitcher astitc...@redhat.com wrote: I'd just like to point out this bug because I think it hasn't got any attention yet, but is a serious regression that crashes a windows broker. As far as I can tell it was caused by r1404590 - Git SHA 00935fcbf0cc (QPID-4394: HA QMF events out of order). This is the first time, as far as I can tell, that the Windows PollableQueue code has been used at all, so although the code compiles it was never used before and it fails. Andrew - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-4436) HA fix qpidd crash when mgmt-enable=no
Alan Conway created QPID-4436: - Summary: HA fix qpidd crash when mgmt-enable=no Key: QPID-4436 URL: https://issues.apache.org/jira/browse/QPID-4436 Project: Qpid Issue Type: Bug Components: C++ Clustering Reporter: Alan Conway Assignee: Alan Conway See also https://bugzilla.redhat.com/show_bug.cgi?id=875660 qpidd crashes if configured with mgmt-enable=no and loading the HA plugin. Caused by incorrect assumption in HA that management is enabled. Added a fix to skip HA initialization if management is off. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-3291) Broker incorrectly sets TTL to 0 for messages about to expire
[ https://issues.apache.org/jira/browse/QPID-3291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated QPID-3291: -- Fix Version/s: 0.12 Broker incorrectly sets TTL to 0 for messages about to expire - Key: QPID-3291 URL: https://issues.apache.org/jira/browse/QPID-3291 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: Andy Goldstein Fix For: 0.12 Attachments: QPID-3291.patch When qpid::broker::Message::adjustTtl() is called prior to delivering a message to a peer, it adjusts the TTL down to reflect the time the message spent in the broker. For a message that has expired, it sets the TTL to 1. The current logic calculates the remaining TTL as the difference, in nanoseconds, between the current time and the expiration time. If this value is greater than 0, it converts the remaining TTL to milliseconds and sets it on the message; otherwise, it sets the TTL to 1. This logic could result in a message that is about to expire receiving a TTL of 0. This would occur if the remaining TTL is somewhere between 1 and 1,000,000 ns. When the division occurs to convert to ms, it would result in some number between 0 and 1, which is rounded down to 0. Instead, this value should be 1. To fix this, the remaining TTL should be compared against 1,000,000. If it is = to that number, then the conversion can proceed successfully; otherwise, the TTL should be set to 1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4379) HA does not properly handle expired messages
[ https://issues.apache.org/jira/browse/QPID-4379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated QPID-4379: -- Fix Version/s: 0.19 HA does not properly handle expired messages - Key: QPID-4379 URL: https://issues.apache.org/jira/browse/QPID-4379 Project: Qpid Issue Type: Bug Components: C++ Clustering Affects Versions: 0.18 Reporter: Alan Conway Assignee: Alan Conway Fix For: 0.19 Description of problem: If a message expires in a queue before the HA replicator is able to browse the message, the message will be skipped and not replicated. This results in the expired message's async completion never being finalized which can stall the original source of the expired message since it will never receive a completion. Oct 18 10:56:02 itcm24 qpidd[48819]: 2012-10-18 10:56:02 [Broker] debug Browser skipping message from 'QueueXyz' Version-Release number of selected component (if applicable): Qpid 0.18 How reproducible: Frequently Steps to Reproduce: 1. It's a race condition between a message expiring in the queue and the HA browsing subscription being able to replicate it. Actual results: The expired message is skipped and its async completion is never finalized. Expected results: While it is not truly necessary for the HA replicating subscription to replicate an expired message, the async completion needs to be finished. Additional info: see also https://bugzilla.redhat.com/show_bug.cgi?id=868360 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4360) Non-ready HA broker can be incorrectly promoted
[ https://issues.apache.org/jira/browse/QPID-4360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated QPID-4360: -- Fix Version/s: 0.19 Non-ready HA broker can be incorrectly promoted Key: QPID-4360 URL: https://issues.apache.org/jira/browse/QPID-4360 Project: Qpid Issue Type: Bug Components: C++ Clustering Affects Versions: 0.18 Reporter: Alan Conway Assignee: Alan Conway Fix For: 0.19 Description of problem: rgmanager can promote a non-ready backup HA broker to primary when other backup brokers are available in the ready state. This can result in loss of messages and broker configuration. Additionally, this can cause the previously ready backups to throw exceptions when connecting to the new primary: Sep 20 10:17:18 itcm12 qpidd[10871]: 2012-09-20 10:17:18 [HA] critical Backup queue Queue1: Replication failed: Invalid position move, preceeds messages Sep 20 10:17:18 itcm12 qpidd[10871]: 2012-09-20 10:17:18 [Protocol] error Unexpected exception: Invalid position move, preceeds messages Sep 20 10:17:18 itcm12 qpidd[10871]: 2012-09-20 10:17:18 [Broker] error Connection 10.3.100.12:43837-10.3.100.105:9006 closed by error: Invalid position move, preceeds messages(501) Version-Release number of selected component (if applicable): Qpid 0.18 How reproducible: 100% Steps to Reproduce: 1. Start a primary and backup broker 2. Inject messages into the primary and ensure messages replicate to backup 3. Restart the primary broker and manually re-promote to primary Actual results: Restarted broker becomes primary Expected results: Restarted broker refuses to become primary since at least one ready backup was discovered within some timeout -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-3351) Provide ability to specify the network interface qpidd should bind to
[ https://issues.apache.org/jira/browse/QPID-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-3351: -- Assignee: Andrew Stitcher Provide ability to specify the network interface qpidd should bind to - Key: QPID-3351 URL: https://issues.apache.org/jira/browse/QPID-3351 Project: Qpid Issue Type: New Feature Components: C++ Broker Reporter: Andy Goldstein Assignee: Andrew Stitcher Priority: Minor Currently, qpidd binds to all network interfaces, which may not be desirable. It would be nice to be able to specify the interface or interfaces to listen on. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Review Request: Fix for Thread object's operator bool()
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8072/ --- Review request for qpid, Andrew Stitcher, Chug Rolke, and Cliff Jansen. Description --- The assert in QPID-4424 was a check for a Thread object not set. This change resolves that problem, but could it really be that easy? Why doesn't the Linux code fail the same way? This addresses bug QPID-4424. https://issues.apache.org/jira/browse/QPID-4424 Diffs - http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/Thread.cpp 1409628 Diff: https://reviews.apache.org/r/8072/diff/ Testing --- Original reproducing test case in QPID-4424 (run broker quiet for 15 seconds). I set a breakpoint at the assert and stepped across it without error. Thanks, Steve Huston
[jira] [Created] (QPID-4437) C++ compile failure on RHEL 5 g++4.1.2
Steve Huston created QPID-4437: -- Summary: C++ compile failure on RHEL 5 g++4.1.2 Key: QPID-4437 URL: https://issues.apache.org/jira/browse/QPID-4437 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Client Affects Versions: 0.19 Environment: RHEL 5, cmake build, g++ 4.1.2 Reporter: Steve Huston Since Monday/Tuesday this week getting a compile error: [ 64%] Building CXX object src/CMakeFiles/qpidmessaging.dir/qpid/messaging/ProtocolRegistry.o cc1plus: warnings being treated as errors /qpidbuilds/trunk/qpid/cpp/src/../include/qpid/RangeSet.h: In instantiation of ‘qpid::RangeSetqpid::framing::SequenceNumber’: /qpidbuilds/trunk/qpid/cpp/src/../include/qpid/framing/SequenceSet.h:32: instantiated from here /qpidbuilds/trunk/qpid/cpp/src/../include/qpid/RangeSet.h:193: warning: lowering visibility of ‘std::ostream qpid::operator(std::ostream, const qpid::RangeSetU) [with U = U, T = qpid::framing::SequenceNumber]’ to match its type make[2]: *** [src/CMakeFiles/qpidmessaging.dir/qpid/messaging/ProtocolRegistry.o] Error 1 make[1]: *** [src/CMakeFiles/qpidmessaging.dir/all] Error 2 make: *** [all] Error 2 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Review Request: Fix for Thread object's operator bool()
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8072/#review13460 --- On the face of it I also can see no reason why bool(impl) should return a different result to bool(impl.get != 0) so I'm a little suspicious that this is really fixing anything! I guess it depends on the precise behaviour of bool(boost::shared_ptrT*) but that should have precisely the same behaviour as extracting the T* and comparing with the null pointer. - Andrew Stitcher On Nov. 15, 2012, 3:05 a.m., Steve Huston wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8072/ --- (Updated Nov. 15, 2012, 3:05 a.m.) Review request for qpid, Andrew Stitcher, Chug Rolke, and Cliff Jansen. Description --- The assert in QPID-4424 was a check for a Thread object not set. This change resolves that problem, but could it really be that easy? Why doesn't the Linux code fail the same way? This addresses bug QPID-4424. https://issues.apache.org/jira/browse/QPID-4424 Diffs - http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/sys/windows/Thread.cpp 1409628 Diff: https://reviews.apache.org/r/8072/diff/ Testing --- Original reproducing test case in QPID-4424 (run broker quiet for 15 seconds). I set a breakpoint at the assert and stepped across it without error. Thanks, Steve Huston
