[jira] Created: (QPID-2565) Topic exchange may NPE during message routing
Topic exchange may NPE during message routing
-
Key: QPID-2565
URL: https://issues.apache.org/jira/browse/QPID-2565
Project: Qpid
Issue Type: Bug
Affects Versions: 0.6, 0.5, M4, 0.7
Reporter: Robbie Gemmell
Fix For: 0.7
Summary:
The Topic exchange may generate an NPE during the message routing process, as
seen in IBAMQ-1344. It is believed this can only be attributed to 'undefined
behaviour' defined in the map.Entry Javadoc, which may be exhibited by
Map.Entry objects returned from an Iterator over the keySet() and entrySet()
results of a ConcurrentHashMap in the event the map is updated directly
following generation of the Map.Entry. The code section in question should be
updated to remove use of Map.Entry since its behaviour in this case cannot be
guaranteed otherwise without additional locking that would hinder performance
of the exchange.
Additional Detail:
It hasnt been possible to reproduce the error thus far, and at first glance it
was believed the code in question should never be able to NPE, as none of the
methods should be able to return null based on the fact they either return a
new Set() or a key/value that can never be null, as null can never be entered
into the map.
However, searching the Sun JDK BugDatabase revealed a historical instance (
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6312056 ) where the
Map.Entry.value() did return null, and although this case was fixed the report
also draws attention to the fact that usage of Map.Entry's returned by the
Iterator from a ConcurrentHashMap are not completely safe, and may exhibit
'undefined behaviour' if the Map is modified thereafter via any means other
than the map.Entry itself, despite the fact the Iterator itself is safe in such
cases.
http://java.sun.com/j2se/1.5.0/docs/api/java/util/Map.Entry.html states:
These Map.Entry objects are valid only for the duration of the iteration; more
formally, the behavior of a map entry is undefined if the backing map has been
modified after the entry was returned by the iterator, except through the
setValue operation on the map entry.
The NPE occurs on the last line of the following code section:
for(Map.EntryAMQQueue, MapMessageFilterRuntimeException, Integer entry :
_filteredQueues.entrySet())
{
if(!queues.contains(entry.getKey()))
{
for(MessageFilterRuntimeException filter : entry.getValue().keySet())
The _filteredQueues map is a ConcurrentHashMap, itself containing
ConcurrentHashMap values. It is not possible for a null to be used as either
key or value in a CHM, and both keyset() or entrySet() return a new Set if none
previously existed. As a result it would seem that it should not be possible
for the above line to ever contain a null unless due to the aforementioned
undefined behaviour.
--
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] Assigned: (QPID-2532) stale lock file
[ https://issues.apache.org/jira/browse/QPID-2532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Sarenik reassigned QPID-2532: - Assignee: Alan Conway I found this issue already reported, reassigning to you as requested in e-mail Message-ID: 4bdedebe.7030...@redhat.com You can find my unsuccessful try to cope with this issue at http://github.com/jsarenik/qpid/commit/23713b2fc999a1fc4119ba06a7296ecd3f8260d4 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 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] Commented: (QPID-2532) stale lock file
[ https://issues.apache.org/jira/browse/QPID-2532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12863764#action_12863764 ] Jan Sarenik commented on QPID-2532: --- From the e-mail I sent recently, the error message is generally the same: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - PASS: run_cluster_test 2010-04-29 20:27:17 warning Connection closed 2010-04-29 20:27:17 warning Connect failed: Connection refused 2010-04-29 20:27:17 warning Connection closed Failed: Cannot establish a connection 2010-04-29 20:27:17 critical Unexpected error: Removing stale lock file /tmp/qpidd.46939.pid Errors stopping brokers on ports: 46939 FAIL: cluster_read_credit PASS: test_watchdog - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - And this was run on qpid-r939184. 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 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] Created: (QPID-2566) FE: add support for include/import-style XML fragment composition in qmf-gen
FE: add support for include/import-style XML fragment composition in qmf-gen Key: QPID-2566 URL: https://issues.apache.org/jira/browse/QPID-2566 Project: Qpid Issue Type: Improvement Components: Qpid Managment Framework Environment: All Reporter: Pete MacKinnon Priority: Minor It would be useful if qmf-gen supported XML parsing such that a target XML file was composed of inclusions or imports of other XML QMF schemas. This would promote modularity and reuse of QMF class definitions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2567) [c++] Timer - possible thread lock ordering violation
[c++] Timer - possible thread lock ordering violation - Key: QPID-2567 URL: https://issues.apache.org/jira/browse/QPID-2567 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.7 Environment: RHEL-6 beta Reporter: Kim van der Riet Assignee: Andrew Stitcher Starting the broker using valgrind and the helgrind thread check tool shows several lock order violations centered around the qpid::sys::Timer class. valgrind --tool=helgrind .libs/lt-qpidd --auth no --log-enable info+ results in the following message (and others that are similar): ==31280== Thread #2: lock order 0x597D548 before 0x59AE350 violated ==31280==at 0x4A0679C: pthread_mutex_lock (hg_intercepts.c:464) ==31280==by 0x4E8C27B: qpid::sys::Mutex::lock() (Mutex.h:116) ==31280==by 0x4E8CD82: qpid::sys::ScopedLockqpid::sys::Mutex::ScopedLock(qpid::sys::Mutex) (Mutex.h:33) ==31280==by 0x56346FF: qpid::sys::Timer::add(boost::intrusive_ptrqpid::sys::TimerTask) (Timer.cpp:162) ==31280==by 0x4EFDCD0: qpid::broker::LinkRegistry::Periodic::fire() (LinkRegistry.cpp:73) ==31280==by 0x563344C: qpid::sys::TimerTask::fireTask() (Timer.cpp:57) ==31280==by 0x5634917: qpid::sys::Timer::fire(boost::intrusive_ptrqpid::sys::TimerTask) (Timer.cpp:190) ==31280==by 0x5633E84: qpid::sys::Timer::run() (Timer.cpp:119) ==31280==by 0x5525BEE: qpid::sys::(anonymous namespace)::runRunnable(void*) (Thread.cpp:35) ==31280==by 0x4A0A1A5: mythread_wrapper (hg_intercepts.c:201) ==31280==by 0x31D6C07950: start_thread (pthread_create.c:301) ==31280==by 0x31D68E4D3C: clone (clone.S:115) ==31280== Required order was established by acquisition of lock at 0x597D548 ==31280==at 0x4A095F6: pthread_cond_wait_WRK (hg_intercepts.c:653) ==31280==by 0x4A096B8: pthread_cond_w...@* (hg_intercepts.c:675) ==31280==by 0x4EF587A: qpid::sys::Condition::wait(qpid::sys::Mutex) (Condition.h:63) ==31280==by 0x4EF5932: qpid::sys::Monitor::wait() (Monitor.h:41) ==31280==by 0x5633AA6: qpid::sys::Timer::run() (Timer.cpp:98) ==31280==by 0x5525BEE: qpid::sys::(anonymous namespace)::runRunnable(void*) (Thread.cpp:35) ==31280==by 0x4A0A1A5: mythread_wrapper (hg_intercepts.c:201) ==31280==by 0x31D6C07950: start_thread (pthread_create.c:301) ==31280==by 0x31D68E4D3C: clone (clone.S:115) ==31280== followed by a later acquisition of lock at 0x59AE350 ==31280==at 0x4A0679C: pthread_mutex_lock (hg_intercepts.c:464) ==31280==by 0x4E8C27B: qpid::sys::Mutex::lock() (Mutex.h:116) ==31280==by 0x4E8CD82: qpid::sys::ScopedLockqpid::sys::Mutex::ScopedLock(qpid::sys::Mutex) (Mutex.h:33) ==31280==by 0x5633B97: qpid::sys::Timer::run() (Timer.cpp:108) ==31280==by 0x5525BEE: qpid::sys::(anonymous namespace)::runRunnable(void*) (Thread.cpp:35) ==31280==by 0x4A0A1A5: mythread_wrapper (hg_intercepts.c:201) ==31280==by 0x31D6C07950: start_thread (pthread_create.c:301) ==31280==by 0x31D68E4D3C: clone (clone.S:115) Running perftest against this broker shows numerous read/write conflicts too. -- 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: cluster_read_credit
On 05/04/2010 07:47 AM, Ján Sáreník wrote: Hi Alan! On Mon, May 03, 2010 at 10:33:34AM -0400, Alan Conway wrote: Please create a JIRA with this info and assign it to me, I'll look into it. https://issues.apache.org/jira/browse/QPID-2532 assigned. I'm not able to reproduce this with r939184 on RHEL5. Do you have a machine where you can reproduce it easily? I'd like to check the cluster*.log files and core file if any. The symptoms suggest that one of the brokers crashed. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Time to start talking about date for 0.8 close down
As our 0.6 release process took quite some time, I believe it is time to assign the 0.8 release manager (any volenteers?) and to agree on a date for feature freeze for 0.8. I would suggest in April 16th -- A random pick. Suggest another if you like. Carl. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2470) Broker does not honour flow-to-disk policy on recovery
[ https://issues.apache.org/jira/browse/QPID-2470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12864055#action_12864055 ] Charles Woerner commented on QPID-2470: --- I was the original reporter of this problem. Thank you very much for making this a priority, Kim, I hope I was able to help the project out a bit. I wonder if there are any plans to backport this to 0.6, or do we need to wait for 0.7 for the fix? Broker does not honour flow-to-disk policy on recovery -- Key: QPID-2470 URL: https://issues.apache.org/jira/browse/QPID-2470 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.7 Reporter: Kim van der Riet Assignee: Kim van der Riet The broker implements a flow-to-disk strategy as a means of retaining message content when a queue policy is exceeded. In this strategy, message content (whether persistent or transient) is written to the store, then released from memory. Before the message may be consumed, the message content must be retrieved from the store. If a broker is stopped while there is flow-to-disk content containing persistent messages, then the broker fails to honour the policy when that content is restored. The policy itself is recovered, however, all message content is restored, even if it violates that policy. In cases where the flow-to-disk content is greater than the available memory, the broker may become unresponsive or fail in its recovery owing to memory starvation. -- 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
