[jira] Updated: (QPID-2256) cluster_test hangs with threads deadlocked on mutex in DeletionManager.
[ https://issues.apache.org/jira/browse/QPID-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated QPID-2256: - Summary: cluster_test hangs with threads deadlocked on mutex in DeletionManager. (was: cluster_test hangs with theads deadlocked on mutex in DeletionManager.) > cluster_test hangs with threads deadlocked on mutex in DeletionManager. > --- > > Key: QPID-2256 > URL: https://issues.apache.org/jira/browse/QPID-2256 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.6 >Reporter: Alan Conway >Assignee: Andrew Stitcher >Priority: Blocker > Fix For: 0.6 > > > Running cluster_test in a loop will fairly quickly result in a deadlock. The > test is blocked waiting for a child broker to exit. The broker appears > deadlocked around a mutex in DeletionManager, here are the stack traces of > the deadlocked broker: > Thread 10 (Thread 0x414b2940 (LWP 2351)): > #0 0x003da400af70 in pthread_cond_timedwait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x2af11703c21d in qpid::sys::Condition::wait (this=0x1accd4e0, > mut...@0x1accd4b8, absoluteti...@0x1acccae0) at > ../../cpp/include/qpid/sys/posix/Condition.h:69 > #2 0x2af11703c48b in qpid::sys::Monitor::wait (this=0x1accd4b8, > absoluteti...@0x1acccae0) at ../../cpp/include/qpid/sys/Monitor.h:45 > #3 0x2af1170396ac in qpid::sys::Timer::run (this=0x1accd4b0) at > ../../cpp/src/qpid/sys/Timer.cpp:139 > #4 0x2af116f4f7cc in runRunnable (p=0x1accd4b0) at > ../../cpp/src/qpid/sys/posix/Thread.cpp:35 > #5 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 > #6 0x003da34d3c2d in clone () from /lib64/libc.so.6 > Thread 9 (Thread 0x4217c940 (LWP 2353)): > #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 > #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at > ../../cpp/include/qpid/sys/posix/Mutex.h:116 > #4 0x2af1169651e6 in ScopedLock (this=0x4217bd70, l...@0x2af11730c360) > at ../../cpp/include/qpid/sys/Mutex.h:33 > #5 0x2af116f5c29a in > qpid::sys::DeletionManager::AllThreadsStatuses::delThreadStatus > (this=0x2af11730c360, t=0x1acd4d00) > at ../../cpp/src/qpid/sys/DeletionManager.h:148 > #6 0x2af116f5c340 in > qpid::sys::DeletionManager::destroyThreadState > () at ../../cpp/src/qpid/sys/DeletionManager.h:83 > #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at > ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 > #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at > ../../cpp/src/qpid/sys/Dispatcher.cpp:37 > #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at > ../../cpp/src/qpid/sys/posix/Thread.cpp:35 > #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 > #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 > Thread 8 (Thread 0x42b7d940 (LWP 2354)): > #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 > #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at > ../../cpp/include/qpid/sys/posix/Mutex.h:116 > #4 0x2af1169651e6 in ScopedLock (this=0x42b7cd70, l...@0x2af11730c360) > at ../../cpp/include/qpid/sys/Mutex.h:33 > #5 0x2af116f5c29a in > qpid::sys::DeletionManager::AllThreadsStatuses::delThreadStatus > (this=0x2af11730c360, t=0x1acd6160) > at ../../cpp/src/qpid/sys/DeletionManager.h:148 > #6 0x2af116f5c340 in > qpid::sys::DeletionManager::destroyThreadState > () at ../../cpp/src/qpid/sys/DeletionManager.h:83 > #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at > ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 > #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at > ../../cpp/src/qpid/sys/Dispatcher.cpp:37 > #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at > ../../cpp/src/qpid/sys/posix/Thread.cpp:35 > #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 > #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 > Thread 7 (Thread 0x4357e940 (LWP 2355)): > #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 > #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x1acd4bc0) at > ../../cpp/include/qpid/sys/posix/Mutex.h:116 > #4 0x2af1169651e6 in ScopedLock (this=0
[jira] Created: (QPID-2260) Build of Release configuration fails
Build of Release configuration fails Key: QPID-2260 URL: https://issues.apache.org/jira/browse/QPID-2260 Project: Qpid Issue Type: Bug Components: WCF/C++ Client Affects Versions: 0.6 Environment: Windows Reporter: Cliff Jansen Priority: Blocker Fix For: 0.6 Locations for the Release intermediaries are not properly resolved. This is known issue #1 in the ReadMe.txt file and prevents non-debug versions of the code from building without user intervention. This should be easy to fix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-2256) cluster_test hangs with theads deadlocked on mutex in DeletionManager.
[ https://issues.apache.org/jira/browse/QPID-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved QPID-2256. --- Resolution: Fixed Fixed by removing unnecessary locking introduced by previous change for QPID-2214 > cluster_test hangs with theads deadlocked on mutex in DeletionManager. > -- > > Key: QPID-2256 > URL: https://issues.apache.org/jira/browse/QPID-2256 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.6 >Reporter: Alan Conway >Assignee: Andrew Stitcher >Priority: Blocker > Fix For: 0.6 > > > Running cluster_test in a loop will fairly quickly result in a deadlock. The > test is blocked waiting for a child broker to exit. The broker appears > deadlocked around a mutex in DeletionManager, here are the stack traces of > the deadlocked broker: > Thread 10 (Thread 0x414b2940 (LWP 2351)): > #0 0x003da400af70 in pthread_cond_timedwait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x2af11703c21d in qpid::sys::Condition::wait (this=0x1accd4e0, > mut...@0x1accd4b8, absoluteti...@0x1acccae0) at > ../../cpp/include/qpid/sys/posix/Condition.h:69 > #2 0x2af11703c48b in qpid::sys::Monitor::wait (this=0x1accd4b8, > absoluteti...@0x1acccae0) at ../../cpp/include/qpid/sys/Monitor.h:45 > #3 0x2af1170396ac in qpid::sys::Timer::run (this=0x1accd4b0) at > ../../cpp/src/qpid/sys/Timer.cpp:139 > #4 0x2af116f4f7cc in runRunnable (p=0x1accd4b0) at > ../../cpp/src/qpid/sys/posix/Thread.cpp:35 > #5 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 > #6 0x003da34d3c2d in clone () from /lib64/libc.so.6 > Thread 9 (Thread 0x4217c940 (LWP 2353)): > #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 > #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at > ../../cpp/include/qpid/sys/posix/Mutex.h:116 > #4 0x2af1169651e6 in ScopedLock (this=0x4217bd70, l...@0x2af11730c360) > at ../../cpp/include/qpid/sys/Mutex.h:33 > #5 0x2af116f5c29a in > qpid::sys::DeletionManager::AllThreadsStatuses::delThreadStatus > (this=0x2af11730c360, t=0x1acd4d00) > at ../../cpp/src/qpid/sys/DeletionManager.h:148 > #6 0x2af116f5c340 in > qpid::sys::DeletionManager::destroyThreadState > () at ../../cpp/src/qpid/sys/DeletionManager.h:83 > #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at > ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 > #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at > ../../cpp/src/qpid/sys/Dispatcher.cpp:37 > #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at > ../../cpp/src/qpid/sys/posix/Thread.cpp:35 > #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 > #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 > Thread 8 (Thread 0x42b7d940 (LWP 2354)): > #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 > #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at > ../../cpp/include/qpid/sys/posix/Mutex.h:116 > #4 0x2af1169651e6 in ScopedLock (this=0x42b7cd70, l...@0x2af11730c360) > at ../../cpp/include/qpid/sys/Mutex.h:33 > #5 0x2af116f5c29a in > qpid::sys::DeletionManager::AllThreadsStatuses::delThreadStatus > (this=0x2af11730c360, t=0x1acd6160) > at ../../cpp/src/qpid/sys/DeletionManager.h:148 > #6 0x2af116f5c340 in > qpid::sys::DeletionManager::destroyThreadState > () at ../../cpp/src/qpid/sys/DeletionManager.h:83 > #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at > ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 > #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at > ../../cpp/src/qpid/sys/Dispatcher.cpp:37 > #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at > ../../cpp/src/qpid/sys/posix/Thread.cpp:35 > #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 > #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 > Thread 7 (Thread 0x4357e940 (LWP 2355)): > #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 > #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x1acd4bc0) at > ../../cpp/include/qpid/sys/posix/Mutex.h:116 > #4 0x2af1169651e6 in ScopedLock (this=0x4357da30, l...@0x1acd4bc0) at > ../../cpp/includ
[jira] Updated: (QPID-2259) Add static build support in cmake for Windows
[ https://issues.apache.org/jira/browse/QPID-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete MacKinnon updated QPID-2259: - Attachment: 0001-Added-cmake-static-build-support-for-Windows.patch Patch to add static build support in cmake for Windows. Enabling QPID_WINDOWS_STATIC means that QPID_LINK_BOOST_DYNAMIC must be OFF for the build to work correctly. > Add static build support in cmake for Windows > - > > Key: QPID-2259 > URL: https://issues.apache.org/jira/browse/QPID-2259 > Project: Qpid > Issue Type: Improvement > Components: Build Tools > Environment: Windows XP SP3, VC++ 9.0 >Reporter: Pete MacKinnon > Attachments: 0001-Added-cmake-static-build-support-for-Windows.patch > > > Some projects (e.g., Condor) that depend on qpid specifically for QMF > integration require static builds of qpid cpp on Windows. Propose a new var > (QPID_WINDOWS_STATIC) that when set makes available static release and debug > configuration targets for VC++. -- 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-2259) Add static build support in cmake for Windows
Add static build support in cmake for Windows - Key: QPID-2259 URL: https://issues.apache.org/jira/browse/QPID-2259 Project: Qpid Issue Type: Improvement Components: Build Tools Environment: Windows XP SP3, VC++ 9.0 Reporter: Pete MacKinnon Some projects (e.g., Condor) that depend on qpid specifically for QMF integration require static builds of qpid cpp on Windows. Propose a new var (QPID_WINDOWS_STATIC) that when set makes available static release and debug configuration targets for VC++. -- 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-2258) [Java Broker] AMQP 0-9-1 Compliance issues
[Java Broker] AMQP 0-9-1 Compliance issues -- Key: QPID-2258 URL: https://issues.apache.org/jira/browse/QPID-2258 Project: Qpid Issue Type: Bug Components: Java Broker, Java Client, Java Tests Reporter: Rob Godfrey Assignee: Rob Godfrey Fix For: 0.6 Testing for compliance with AMQP0-9-1 has shown up errors particuarly around dealing with the redeclaration of queues and handling queue exclusivity. When implementing these features (such as disallowing redeclaration from exclusive to non-exclusive or durable to non-durable) it became apparent that some of our system tests were performing such erroneous redeclaration. Fixes are mostly in the method handlers in the Java Broker -- 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: First Qpid 0.6 Beta Release available for download and testing
You are indeed correct. I didn't actually look at the script before mentioning it as I just presumed it was the Git addition that did it hehe. Oh well, still needs fixing :) I'll look at it tomorrow, shouldn't take long to add a property check. I'll probably standardise the different areas that doo it too as I think they do it independently and slightly differently, and I recall there being an issue whereby if you dont actually have the svnversion command on your path Ant encounters an infinite loop property definition and refuses to build a second time ;) Robbie > -Original Message- > From: Andrew Stitcher [mailto:astitc...@redhat.com] > Sent: 09 December 2009 22:24 > To: dev@qpid.apache.org > Subject: RE: First Qpid 0.6 Beta Release available for download and > testing > > On Wed, 2009-12-09 at 22:01 +, Robbie Gemmell wrote: > > No that explains it, it's just the same effect as using git would > have caused, I just assumed since you added that... :) > > > > By using svn export you don't get the .svn/ metadata directories > within each directory, and so svnversion cant detect the version when > run and assumes it was exported (which in this case, it actually was). > > > > I will have a look at updating the Ant scripting to allow specifying > the revision to handle this. > > FWIW in that case this isn't a regression as I believe previous > releases > were produced using svn export also. > > A > > > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: First Qpid 0.6 Beta Release available for download and testing
On Wed, 2009-12-09 at 22:01 +, Robbie Gemmell wrote: > No that explains it, it's just the same effect as using git would have > caused, I just assumed since you added that... :) > > By using svn export you don't get the .svn/ metadata directories within each > directory, and so svnversion cant detect the version when run and assumes it > was exported (which in this case, it actually was). > > I will have a look at updating the Ant scripting to allow specifying the > revision to handle this. FWIW in that case this isn't a regression as I believe previous releases were produced using svn export also. A - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Closed: (QPID-1027) verify script is sensitive to shell in use
[ https://issues.apache.org/jira/browse/QPID-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway closed QPID-1027. - Resolution: Won't Fix This doesn't seem to be a problem for most users, marking this wont fix. If we really wanted to fix it, there are probably more scripts than just verify that have bashisms. > verify script is sensitive to shell in use > -- > > Key: QPID-1027 > URL: https://issues.apache.org/jira/browse/QPID-1027 > Project: Qpid > Issue Type: Bug > Components: Qpid Examples >Affects Versions: M4 >Reporter: Senaka Fernando >Assignee: Alan Conway > Attachments: verify.patch.txt, verify_patch_java.patch.txt > > > verify (found in C++ examples) script is sensitive to the shell in use. And, > the fix incorporated in the attached patch that will specifically revert the > script to use the type of shell in which it is being run. I was inspired by > [1], which better describes the problem of scripts that are sensitive to the > type of shell. > [1] http://forum.java.sun.com/thread.jspa?messageID=9948827&tstart=0 > Regards, > Senaka -- 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: First Qpid 0.6 Beta Release available for download and testing
No that explains it, it's just the same effect as using git would have caused, I just assumed since you added that... :) By using svn export you don't get the .svn/ metadata directories within each directory, and so svnversion cant detect the version when run and assumes it was exported (which in this case, it actually was). I will have a look at updating the Ant scripting to allow specifying the revision to handle this. Robbie > -Original Message- > From: Andrew Stitcher [mailto:astitc...@redhat.com] > Sent: 09 December 2009 21:55 > To: dev@qpid.apache.org > Subject: RE: First Qpid 0.6 Beta Release available for download and > testing > > On Wed, 2009-12-09 at 20:36 +, Robbie Gemmell wrote: > > I have updated (r888939) the build process to and release script so > the QMan package is generated and copied over. > > > > Additionally, I have noticed that because you are using Git > (presumably, since the ability was added recently) to do the checkout > the Java modules are failing to identify the SVN revision used in the > build and so are generating property files that contain "exported" > where the revision should be, since svnversion didnt find the .svn > folders. As a result, "exported" will show up wherever the revision > would normally be mentioned, eg broker startup. > > > > The actual released artifacts were produced from an svn export, not git > - that was for convenience leading up to a final release as "svn > export" > is slow because it needs to go over the internet. > > So that doesn't explain this (unless I've made a mistake). > > Andrew > > > One way to handle this would be to add a property in the ant build > process that can be set via command line in the release script with the > value parsed from Git, and modify the build process to only use > svnversion to figure it out the revision if that hasn't been set. > > That's certainly not in my skill set re java, I'm just about capable of > running release.sh and seeing whether java built! > > Andrew > > > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: First Qpid 0.6 Beta Release available for download and testing
On Wed, 2009-12-09 at 20:36 +, Robbie Gemmell wrote: > I have updated (r888939) the build process to and release script so the QMan > package is generated and copied over. > > Additionally, I have noticed that because you are using Git (presumably, > since the ability was added recently) to do the checkout the Java modules are > failing to identify the SVN revision used in the build and so are generating > property files that contain "exported" where the revision should be, since > svnversion didnt find the .svn folders. As a result, "exported" will show up > wherever the revision would normally be mentioned, eg broker startup. > The actual released artifacts were produced from an svn export, not git - that was for convenience leading up to a final release as "svn export" is slow because it needs to go over the internet. So that doesn't explain this (unless I've made a mistake). Andrew > One way to handle this would be to add a property in the ant build process > that can be set via command line in the release script with the value parsed > from Git, and modify the build process to only use svnversion to figure it > out the revision if that hasn't been set. That's certainly not in my skill set re java, I'm just about capable of running release.sh and seeing whether java built! Andrew - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [QMF] public github repo for QMFv2 api work
On Wed, 2009-12-09 at 20:25 +, Robert Greig wrote: > > I think the safest option is to expose your work through a series of JIRA's. > > If we need to make the code available immediately and/or collaborate > > with others we could create a branch. > > You could work off the branch and then Ted could apply the patches as > > an when they are made available. > > I think this approach - creating patches and applying them to Jira is > very poor for several reasons: > > 1) it is a pain to create patches and attach them to jira (at least I think > so) > 2) it is a pain for a reviewer to extract them from the jira, review and > commit > 3) because of the above it encourages the large code drops that we > have discussed recently I'd say that using git is pretty good for the purposes of working in the open conveniently but still producing patches attached to jiras. The alternative would be for Ken to work in private producing patches, at the end of the process. Surely working in the open based on the git.apache.org/qpid repo and producing git patches relative to that using git format-patch will ultimately make it very easy for anyone to apply the patches with no ambiguity, and in the meantime allow us to also pull from his work. Andrew - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [QMF] public github repo for QMFv2 api work
Robert Greig wrote: 2009/12/9 Carl Trieloff : In the ASF, unfortunately to give commit rights to anything we need to get through the committer nomination and vote process. Do you (or anyone else) know what the rationale for this is? Main thing is infra does not want to deal with high churn on accounts etc of people that may not stick around. So for net new committers for apache this is the process. Carl.
RE: [QMF] public github repo for QMFv2 api work
As an even more recent committer than Steve, ill chime in too. I don't think anyone would argue against it being easiest to have commit rights from the get go, even if only to a branch. Attaching patches to JIRAs does get a bit tiresome if they aren't picked up for a while, or if you start tripping over previous patches while working on unrelated issues in similar areas, meaning that they need to be applied in a particular order etc. I was working back and forth all over the place and this still only happened a couple times, Ken shouldn't have as much of an issue with that as all the work is contained on the same issue towards the same goal. Also, that's mostly only an issue when using SVN locally... Git really does make the world a better place, especially when tracking a repository you don't have commit rights to, as it's easy to maintain your own local (or remote via git-hub) commits and branches. And if you are working on the same issue in the same area all the time anyway, a sequential nature of patches will emerge. I think a lot of the existing committers are using Git locally now too, so it would be easy for Ken to generate a series of patches with git-format-patch and attach them in a zip to JIRA, and then it's a similarly simple one-off Git command for a reviewer to apply all of them at once. Then once any of Kens patches were applied in SVN, Git will figure that out easily. So, yes it would have been easier...but tracking trunk is not necessarily that big a hassle to someone using Git anyway. Also, the entire process sort of helps with integration into the project and workflow required to be an apache committer...and damnit, Steve has just beaten me as I typed way too much lol ;) Robbie > -Original Message- > From: Robert Greig [mailto:robert.j.gr...@gmail.com] > Sent: 09 December 2009 20:25 > To: dev@qpid.apache.org > Subject: Re: [QMF] public github repo for QMFv2 api work > > Is it not possible for us to create a branch and give Ken commit > rights *only* to the branch? As long as he has signed the CLA that > should be much simpler all round since someone just has to merge - Ken > could use Jiras or the mailing list to prompt a buddy to review and > merge at appropriate points. > > For the rest of us who are interested in what is going on but not so > interested that we are willing to mess about with patches from Jira > this would be better too. > > Steve, as someone who had to go through the process of jiras > relatively recently, would that have been easier for you? > - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: [QMF] public github repo for QMFv2 api work
> -Original Message- > From: Robert Greig [mailto:robert.j.gr...@gmail.com] > Sent: Wednesday, December 09, 2009 3:25 PM > To: dev@qpid.apache.org > Subject: Re: [QMF] public github repo for QMFv2 api work > > > > I think the safest option is to expose your work through a > series of JIRA's. > > If we need to make the code available immediately and/or collaborate > > with others we could create a branch. > > You could work off the branch and then Ted could apply the > patches as > > an when they are made available. > > I think this approach - creating patches and applying them to Jira is > very poor for several reasons: > > 1) it is a pain to create patches and attach them to jira (at > least I think so) > 2) it is a pain for a reviewer to extract them from the jira, > review and commit > 3) because of the above it encourages the large code drops that we > have discussed recently > > Is it not possible for us to create a branch and give Ken commit > rights *only* to the branch? As long as he has signed the CLA that > should be much simpler all round since someone just has to merge - Ken > could use Jiras or the mailing list to prompt a buddy to review and > merge at appropriate points. > > For the rest of us who are interested in what is going on but not so > interested that we are willing to mess about with patches from Jira > this would be better too. > > Steve, as someone who had to go through the process of jiras > relatively recently, would that have been easier for you? I think Carl's comments made this moot, but... Yes, it would have been easier for me at the time. But it would have been worse in the end. Having to do patches and jiras had the benefits: - Something to notify the community that there was something to review. Not being familiar with the personnel at the time, this was what got me some answers quickly on who was most related to what I needed to know. - Got me into the Apache Way quicker and I think it has helped in the long run. -Steve - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Project Etiquette
Hi Rafi, Thanks for taking the time to write these. I think they're a good idea to have for new people. At risk of incurring your wrath - I found it them a little long, at first reading. I wonder if you'd consider a more concise version - be happy to have a shot at it if that'd be helpful and not cross making ? I'd like to think we should welcome people in, tell them what they might need to know but I'm hoping we won't scare them off. What do you think ? Regards, Marnie On Wed, Dec 9, 2009 at 11:55 AM, Rafael Schloming wrote: > FWIW, the stuff I wrote was all intended for the benefit of new guys > especially, even though I think it is equally good for us to have it written > down for ourselves. > > I'm happy to add to it with some guidelines specifically for new > contributors, I'm just less sure of what those are since it's been a while > since I was a new contributor. > > If anyone has specific suggestions, please post and I'm happy to try to > incorporate them somehow. As I mentioned, this wasn't intended to be a > complete and definitive document, just a start that can evolve. > > --Rafael > > > Sam Joyce wrote: > >> Hi Folks, >> Personally I think Carl's idea is a good one, as I am new :) I was >> involved with QPID and AMQP a few years ago and have only just come back to >> the fold. I think having a "getting involved - etiquette" section is a good >> idea. As has already been mentioned, there is a lot of latent awareness >> about how to go about things, but as a new member of the community it would >> certainly be of benefit to me to be able to read about it! >> >> cheers, >> Sam. >> >> Carl Trieloff wrote: >> >>> Robert Godfrey wrote: >>> 2009/12/8 Rafael Schloming > A number of recent threads have made it clear that we have a fair > amount of > unspoken etiquette about how we do things around here, and the fact > that it > is unspoken can be confusing to newcomers and old-timers alike. > > Looking at a few other apache project web sites, they often seem to > have a > page or two devoted to documenting their project etiquette. I think > this > would be a good thing for us to have as well, and I've taken the > liberty of > trying to seed this effort with some content. > > I think there are some obvious places where it would make sense to > formalize some of this etiquette into some lightweight process, e.g. > having > maintainers files in svn, having a sandbox for new code contributions, > etc, > however this text is *not* intended to be a proposal for that sort of > thing, > merely an attempt to put into words what I believe most of us consider > to be > the status quo wrt the unspoken etiquette of the project. > > Of course the problem with unspoken etiquette is that we might not all > have > the same concept of what it actually is, so please let me know if you > disagree with something I've written or you think something important > is > missing. > > --Rafael > > > All this sounds very sensible to me; and there's nothing I can immediately think of that I would like to add. Having this on a "Getting Involved" section of the website, along, perhaps, with a list of the "Big Ideas" people are currently working on would seem to make a lot of sense... -- Rob >>> >>> Should we also add a getting involved Etiquette section, i.e. if you are >>> new, how should I work with the team... >>> >>> Carl. >>> >>> >>> >>> >> >> - >> Apache Qpid - AMQP Messaging Implementation >> Project: http://qpid.apache.org >> Use/Interact: mailto:dev-subscr...@qpid.apache.org >> >> > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > >
Re: [QMF] public github repo for QMFv2 api work
2009/12/9 Carl Trieloff : > In the ASF, unfortunately to give commit rights to anything we need to get > through the > committer nomination and vote process. Do you (or anyone else) know what the rationale for this is? Thanks, Robert - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [VOTE] Committership Criteria
> As there have been no comments or questions on the discussion thread, I'm > going to move this to a vote: > > Qualities we look for: > > - A candidate must demonstrate an understanding of how our project >is structured and how we work. > > - A candidate must communicate openly about work planned/in-progress. > > - A candidate must demonstrate expertise in a significant area of >the existing code base. > > - A candidate must demonstrate an extended commitment to the >project. > > Tests for these qualities: > > - contacting the right team members to discuss changes > > - actively soliciting feedback for significant changes or new >development > > - multiple independent contributions over a period of several months > > - sponsorship by someone who has worked directly with the candidate >reviewing and committing patches > > - detailed positive feedback from those who have worked directly >with the candidate > > - a record of patches that maintain or improve the quality of the >code without the need for feedback or rework > > Please cast your vote below: > > [ ] Adopt the above statements as our official committership criteria. > [+1] Adopt the above statements as our official committership criteria.
RE: First Qpid 0.6 Beta Release available for download and testing
I have updated (r888939) the build process to and release script so the QMan package is generated and copied over. Additionally, I have noticed that because you are using Git (presumably, since the ability was added recently) to do the checkout the Java modules are failing to identify the SVN revision used in the build and so are generating property files that contain "exported" where the revision should be, since svnversion didnt find the .svn folders. As a result, "exported" will show up wherever the revision would normally be mentioned, eg broker startup. One way to handle this would be to add a property in the ant build process that can be set via command line in the release script with the value parsed from Git, and modify the build process to only use svnversion to figure it out the revision if that hasn't been set. Robbie < 2nd attempt at send as I didn't notice the first time that it only replied directly to me ;-) > > -Original Message- > From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com] > Sent: 09 December 2009 17:10 > To: dev@qpid.apache.org > Subject: RE: First Qpid 0.6 Beta Release available for download and > testing > > The single component package for QMan is not currently being created > (although I seem to recall this happening with 0.5 as well). I think it > uses a slightly non standard target to build the package just now, so > ill see if I can modify it to be the same as the others and then the > release script just needs updated to perform the copy. > > Robbie > > > -Original Message- > > From: Andrew Stitcher [mailto:astitc...@redhat.com] > > Sent: 03 December 2009 00:54 > > To: dev@qpid.apache.org > > Subject: First Qpid 0.6 Beta Release available for download and > testing > > > > Apologies for the long message, but there actually is a fair bit to > > say: > > > > I've uploaded the artifacts for a 0.6 beta release to > qpid.apache.org: > > > > http://qpid.apache.org/dist/qpid-0.6beta1/ > > > > Please download and test this release. No, really, please download > and > > at least look at it. > > > > I've called it a beta because, it seems to me in the area that I know > > (C > > ++) and in the currently outstanding bugs it seems very usable. > > > > I plan that every one should give this a good beating for 1-2 weeks > and > > then I'll spin a release candidate, or if there are many problems > found > > and fixed a beta2. > > > > So all being well I'd like to vote on releasing 0.6 in a couple of > > weeks. > > > > --- > > > > The status of this beta: > > > > My testing has been building the C++ tar source under various linux > > platforms (using this release or very slightly earlier ones). > > Essentially "configure; make check". > > > > Fedora 11/Fedora 12 (these both tested with the same results): > > > > Autotools build is fine including all broker modules. It doesn't seem > > that the build as it stands in the C++ source release builds the qmf > > bindings. > > > > Cmake build is mostly fine - however the clustering module doesn't > > build > > due to a complication of recent versions of boost. And r886259 breaks > > building the clustering tests (due to missing the new > > tests/cluster.cmake from EXTRA_DIST) > > > > Red Hat Enterprise Linux 5: > > > > Autotools builds fine. > > > > Cmake builds fine (but this was a slightly earlier release and this > > would have been broken by r886259 as above). > > > > Debian 5 (lenny). > > > > Neither the clustering module nor the XML module have their necessary > > prerequisites so can't be built here. > > > > Given this both autotools and cmake builds were fine. > > > > --- > > > > Overall Release Status: > > > > I've put up a page for the release on the wiki: > > > > http://cwiki.apache.org/confluence/display/qpid/0.6+Release > > > > (don't use the mirror on qpid.apache.org as it won't have the > > dynamically updated bug list) > > > > Please edit the release page to add your understanding to it - it's a > > little biased to the areas that I know about presently. > > > > One area that needs attention is the Release notes, I appeal to you > to > > add any release notes to that wiki page and I will turn them into > > something to put in the release itself. Otherwise the only release > > notes > > will be for the C++ code and whatever I can get from the 0.6 fixed > > bugs. > > > > --- > > > > Deficiencies: > > > > I've removed the separate dotnet package from the release as it > doesn't > > build for me using the release script. More about this separately. > > > > I've not packaged the wcf code separately as I've no idea how it > should > > look and I doubt I could build it under Linux anyway. > > > > I'm concerned there appear to be 5 13Mb eclipse plugins labelled for > > various platforms - is this really necessary - it certainly took a > long > > time to upload and constitutes a large amount of space. > > > > --- > > > > At this point I suggest that any bugs important enough to be fixed > > before the
Re: [QMF] public github repo for QMFv2 api work
Robert Greig wrote: I think the safest option is to expose your work through a series of JIRA's. If we need to make the code available immediately and/or collaborate with others we could create a branch. You could work off the branch and then Ted could apply the patches as an when they are made available. I think this approach - creating patches and applying them to Jira is very poor for several reasons: 1) it is a pain to create patches and attach them to jira (at least I think so) 2) it is a pain for a reviewer to extract them from the jira, review and commit 3) because of the above it encourages the large code drops that we have discussed recently Is it not possible for us to create a branch and give Ken commit rights *only* to the branch? As long as he has signed the CLA that should be much simpler all round since someone just has to merge - Ken could use Jiras or the mailing list to prompt a buddy to review and merge at appropriate points. For the rest of us who are interested in what is going on but not so interested that we are willing to mess about with patches from Jira this would be better too. Steve, as someone who had to go through the process of jiras relatively recently, would that have been easier for you? In the ASF, unfortunately to give commit rights to anything we need to get through the committer nomination and vote process. He can hold a GIT and then update JIRA with patches as he goes and someone then has to take the patches from from JIRA due to lic issues on the JIRA click through. best if for new people to be visible on the project and lists to get to committership. Carl.
Re: [QMF] public github repo for QMFv2 api work
> I think the safest option is to expose your work through a series of JIRA's. > If we need to make the code available immediately and/or collaborate > with others we could create a branch. > You could work off the branch and then Ted could apply the patches as > an when they are made available. I think this approach - creating patches and applying them to Jira is very poor for several reasons: 1) it is a pain to create patches and attach them to jira (at least I think so) 2) it is a pain for a reviewer to extract them from the jira, review and commit 3) because of the above it encourages the large code drops that we have discussed recently Is it not possible for us to create a branch and give Ken commit rights *only* to the branch? As long as he has signed the CLA that should be much simpler all round since someone just has to merge - Ken could use Jiras or the mailing list to prompt a buddy to review and merge at appropriate points. For the rest of us who are interested in what is going on but not so interested that we are willing to mess about with patches from Jira this would be better too. Steve, as someone who had to go through the process of jiras relatively recently, would that have been easier for you? Thanks, Robert - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Release artifacts
Robbie Gemmell wrote: I think you have misunderstood what I meant by that entirely, as by "the build system in general to always generate the release style artifacts" I meant exactly what you are suggesting, that the build system should be modified to generate something we can simply take a (partial) tarball of and end up with what we release...ie release style. The reason there is anything else in place right now is that they arent, IMO. Sorry, I see how you meant that now. My mistake. Clearly I've been too eager to rant recently. ;) --Rafael - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-1753) Create QMan / WsDmAdapter package
[ https://issues.apache.org/jira/browse/QPID-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788284#action_12788284 ] Robbie Gemmell commented on QPID-1753: -- Updated the build.xml for the QMan module to override the dummy holder "release-bin" task from module.xml and invoke its packaging process. Updated the release.sh script to copy the artifact during release. > Create QMan / WsDmAdapter package > - > > Key: QPID-1753 > URL: https://issues.apache.org/jira/browse/QPID-1753 > Project: Qpid > Issue Type: Sub-task > Components: Build Tools >Reporter: Martin Ritchie >Assignee: Robbie Gemmell > Fix For: 0.6 > > -- 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-2256) cluster_test hangs with theads deadlocked on mutex in DeletionManager.
[ https://issues.apache.org/jira/browse/QPID-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher reassigned QPID-2256: - Assignee: Andrew Stitcher (was: Alan Conway) > cluster_test hangs with theads deadlocked on mutex in DeletionManager. > -- > > Key: QPID-2256 > URL: https://issues.apache.org/jira/browse/QPID-2256 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.6 >Reporter: Alan Conway >Assignee: Andrew Stitcher >Priority: Blocker > Fix For: 0.6 > > > Running cluster_test in a loop will fairly quickly result in a deadlock. The > test is blocked waiting for a child broker to exit. The broker appears > deadlocked around a mutex in DeletionManager, here are the stack traces of > the deadlocked broker: > Thread 10 (Thread 0x414b2940 (LWP 2351)): > #0 0x003da400af70 in pthread_cond_timedwait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x2af11703c21d in qpid::sys::Condition::wait (this=0x1accd4e0, > mut...@0x1accd4b8, absoluteti...@0x1acccae0) at > ../../cpp/include/qpid/sys/posix/Condition.h:69 > #2 0x2af11703c48b in qpid::sys::Monitor::wait (this=0x1accd4b8, > absoluteti...@0x1acccae0) at ../../cpp/include/qpid/sys/Monitor.h:45 > #3 0x2af1170396ac in qpid::sys::Timer::run (this=0x1accd4b0) at > ../../cpp/src/qpid/sys/Timer.cpp:139 > #4 0x2af116f4f7cc in runRunnable (p=0x1accd4b0) at > ../../cpp/src/qpid/sys/posix/Thread.cpp:35 > #5 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 > #6 0x003da34d3c2d in clone () from /lib64/libc.so.6 > Thread 9 (Thread 0x4217c940 (LWP 2353)): > #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 > #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at > ../../cpp/include/qpid/sys/posix/Mutex.h:116 > #4 0x2af1169651e6 in ScopedLock (this=0x4217bd70, l...@0x2af11730c360) > at ../../cpp/include/qpid/sys/Mutex.h:33 > #5 0x2af116f5c29a in > qpid::sys::DeletionManager::AllThreadsStatuses::delThreadStatus > (this=0x2af11730c360, t=0x1acd4d00) > at ../../cpp/src/qpid/sys/DeletionManager.h:148 > #6 0x2af116f5c340 in > qpid::sys::DeletionManager::destroyThreadState > () at ../../cpp/src/qpid/sys/DeletionManager.h:83 > #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at > ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 > #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at > ../../cpp/src/qpid/sys/Dispatcher.cpp:37 > #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at > ../../cpp/src/qpid/sys/posix/Thread.cpp:35 > #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 > #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 > Thread 8 (Thread 0x42b7d940 (LWP 2354)): > #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 > #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at > ../../cpp/include/qpid/sys/posix/Mutex.h:116 > #4 0x2af1169651e6 in ScopedLock (this=0x42b7cd70, l...@0x2af11730c360) > at ../../cpp/include/qpid/sys/Mutex.h:33 > #5 0x2af116f5c29a in > qpid::sys::DeletionManager::AllThreadsStatuses::delThreadStatus > (this=0x2af11730c360, t=0x1acd6160) > at ../../cpp/src/qpid/sys/DeletionManager.h:148 > #6 0x2af116f5c340 in > qpid::sys::DeletionManager::destroyThreadState > () at ../../cpp/src/qpid/sys/DeletionManager.h:83 > #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at > ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 > #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at > ../../cpp/src/qpid/sys/Dispatcher.cpp:37 > #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at > ../../cpp/src/qpid/sys/posix/Thread.cpp:35 > #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 > #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 > Thread 7 (Thread 0x4357e940 (LWP 2355)): > #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 > #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x1acd4bc0) at > ../../cpp/include/qpid/sys/posix/Mutex.h:116 > #4 0x2af1169651e6 in ScopedLock (this=0x4357da30, l...@0x1acd4bc0) at > ../../cpp/include/qpid/sys/Mutex.h:33 > #5 0x2af116f5b162 in >
RE: Release artifacts
I think you have misunderstood what I meant by that entirely, as by "the build system in general to always generate the release style artifacts" I meant exactly what you are suggesting, that the build system should be modified to generate something we can simply take a (partial) tarball of and end up with what we release...ie release style. The reason there is anything else in place right now is that they arent, IMO. Robbie > -Original Message- > From: Rafael Schloming [mailto:rafa...@redhat.com] > Sent: 09 December 2009 19:38 > To: dev@qpid.apache.org > Subject: Re: Release artifacts > > Robbie Gemmell wrote: > > I can see what you are saying and thus agree that it would be > beneficial for the build system in general to always generate the > release style artifacts. However I don't see that this means we > shouldn't use what we have at our disposal now in order to give our > users a better experience than we currently are. > > I'm saying more than just always generate the release style artifacts, > they need to be generated in such a way that starting up a devel server > is using the same scripting and artifacts that the end user encounters > when they attempt the same sort of exercise from the release tarball. > Moreover I'm saying that there should be no such thing as "release > style > artifacts", only build artifacts, and the various release tarballs > should simply be archives (either whole or in part) of the build > artifacts. > > And on top of all this it needs to be simple, fast, and properly do > incremental builds so that it's actually usable for those of us who > have > chosen not to participate in this passing IDE fad. ;) > > I don't want to seem discouraging, I agree with your goals, I'm just > particular about how we get there and I'm not eager to pile another > quick hack on top of things. Doing all this without hacks shouldn't be > terribly difficult as long as we figure out what we want first and > choose something sensible. > > --Rafael > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2257) Tests for Transactional WCF channel
Tests for Transactional WCF channel --- Key: QPID-2257 URL: https://issues.apache.org/jira/browse/QPID-2257 Project: Qpid Issue Type: Task Components: WCF/C++ Client Affects Versions: 0.6 Reporter: Devang Gandhi Fix For: 0.6 New tests are needed for the transactional functionality of the WCF channel. -- 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-2256) cluster_test hangs with theads deadlocked on mutex in DeletionManager.
[ https://issues.apache.org/jira/browse/QPID-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788275#action_12788275 ] Alan Conway commented on QPID-2256: --- There is a lock hierarchy error causing the deadlock as follows # threads 1-6,8,9 DeletionManager::destroyThreadState threadStatus->lock AllThreadsStatuses::delThreadStatus lock # thread 7 AllThreadsStatuses::handleAdder ptr->lock AllThreadsStatuses::addHandle lock ptr->lock And threadStatus == ptr threadStatus == ptr and the same AllThreadsStatuses instance is involved in all cases. > cluster_test hangs with theads deadlocked on mutex in DeletionManager. > -- > > Key: QPID-2256 > URL: https://issues.apache.org/jira/browse/QPID-2256 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.6 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Blocker > Fix For: 0.6 > > > Running cluster_test in a loop will fairly quickly result in a deadlock. The > test is blocked waiting for a child broker to exit. The broker appears > deadlocked around a mutex in DeletionManager, here are the stack traces of > the deadlocked broker: > Thread 10 (Thread 0x414b2940 (LWP 2351)): > #0 0x003da400af70 in pthread_cond_timedwait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x2af11703c21d in qpid::sys::Condition::wait (this=0x1accd4e0, > mut...@0x1accd4b8, absoluteti...@0x1acccae0) at > ../../cpp/include/qpid/sys/posix/Condition.h:69 > #2 0x2af11703c48b in qpid::sys::Monitor::wait (this=0x1accd4b8, > absoluteti...@0x1acccae0) at ../../cpp/include/qpid/sys/Monitor.h:45 > #3 0x2af1170396ac in qpid::sys::Timer::run (this=0x1accd4b0) at > ../../cpp/src/qpid/sys/Timer.cpp:139 > #4 0x2af116f4f7cc in runRunnable (p=0x1accd4b0) at > ../../cpp/src/qpid/sys/posix/Thread.cpp:35 > #5 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 > #6 0x003da34d3c2d in clone () from /lib64/libc.so.6 > Thread 9 (Thread 0x4217c940 (LWP 2353)): > #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 > #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at > ../../cpp/include/qpid/sys/posix/Mutex.h:116 > #4 0x2af1169651e6 in ScopedLock (this=0x4217bd70, l...@0x2af11730c360) > at ../../cpp/include/qpid/sys/Mutex.h:33 > #5 0x2af116f5c29a in > qpid::sys::DeletionManager::AllThreadsStatuses::delThreadStatus > (this=0x2af11730c360, t=0x1acd4d00) > at ../../cpp/src/qpid/sys/DeletionManager.h:148 > #6 0x2af116f5c340 in > qpid::sys::DeletionManager::destroyThreadState > () at ../../cpp/src/qpid/sys/DeletionManager.h:83 > #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at > ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 > #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at > ../../cpp/src/qpid/sys/Dispatcher.cpp:37 > #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at > ../../cpp/src/qpid/sys/posix/Thread.cpp:35 > #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 > #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 > Thread 8 (Thread 0x42b7d940 (LWP 2354)): > #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 > #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at > ../../cpp/include/qpid/sys/posix/Mutex.h:116 > #4 0x2af1169651e6 in ScopedLock (this=0x42b7cd70, l...@0x2af11730c360) > at ../../cpp/include/qpid/sys/Mutex.h:33 > #5 0x2af116f5c29a in > qpid::sys::DeletionManager::AllThreadsStatuses::delThreadStatus > (this=0x2af11730c360, t=0x1acd6160) > at ../../cpp/src/qpid/sys/DeletionManager.h:148 > #6 0x2af116f5c340 in > qpid::sys::DeletionManager::destroyThreadState > () at ../../cpp/src/qpid/sys/DeletionManager.h:83 > #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at > ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 > #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at > ../../cpp/src/qpid/sys/Dispatcher.cpp:37 > #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at > ../../cpp/src/qpid/sys/posix/Thread.cpp:35 > #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 > #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 > Thread 7 (Thread 0x4357e940 (LWP 2355)): > #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x000
[jira] Updated: (QPID-1753) Create QMan / WsDmAdapter package
[ https://issues.apache.org/jira/browse/QPID-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-1753: - Fix Version/s: (was: 0.5) 0.6 Assignee: Robbie Gemmell (was: Martin Ritchie) > Create QMan / WsDmAdapter package > - > > Key: QPID-1753 > URL: https://issues.apache.org/jira/browse/QPID-1753 > Project: Qpid > Issue Type: Sub-task > Components: Build Tools >Reporter: Martin Ritchie >Assignee: Robbie Gemmell > Fix For: 0.6 > > -- 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: Release artifacts
Robbie Gemmell wrote: I can see what you are saying and thus agree that it would be beneficial for the build system in general to always generate the release style artifacts. However I don't see that this means we shouldn't use what we have at our disposal now in order to give our users a better experience than we currently are. I'm saying more than just always generate the release style artifacts, they need to be generated in such a way that starting up a devel server is using the same scripting and artifacts that the end user encounters when they attempt the same sort of exercise from the release tarball. Moreover I'm saying that there should be no such thing as "release style artifacts", only build artifacts, and the various release tarballs should simply be archives (either whole or in part) of the build artifacts. And on top of all this it needs to be simple, fast, and properly do incremental builds so that it's actually usable for those of us who have chosen not to participate in this passing IDE fad. ;) I don't want to seem discouraging, I agree with your goals, I'm just particular about how we get there and I'm not eager to pile another quick hack on top of things. Doing all this without hacks shouldn't be terribly difficult as long as we figure out what we want first and choose something sensible. --Rafael - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2256) cluster_test hangs with theads deadlocked on mutex in DeletionManager.
[ https://issues.apache.org/jira/browse/QPID-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788259#action_12788259 ] Andrew Stitcher commented on QPID-2256: --- This might be related to having client and broker in the same process, as under this one case the DeletionManager would be shared. > cluster_test hangs with theads deadlocked on mutex in DeletionManager. > -- > > Key: QPID-2256 > URL: https://issues.apache.org/jira/browse/QPID-2256 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.6 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Blocker > Fix For: 0.6 > > > Running cluster_test in a loop will fairly quickly result in a deadlock. The > test is blocked waiting for a child broker to exit. The broker appears > deadlocked around a mutex in DeletionManager, here are the stack traces of > the deadlocked broker: > Thread 10 (Thread 0x414b2940 (LWP 2351)): > #0 0x003da400af70 in pthread_cond_timedwait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x2af11703c21d in qpid::sys::Condition::wait (this=0x1accd4e0, > mut...@0x1accd4b8, absoluteti...@0x1acccae0) at > ../../cpp/include/qpid/sys/posix/Condition.h:69 > #2 0x2af11703c48b in qpid::sys::Monitor::wait (this=0x1accd4b8, > absoluteti...@0x1acccae0) at ../../cpp/include/qpid/sys/Monitor.h:45 > #3 0x2af1170396ac in qpid::sys::Timer::run (this=0x1accd4b0) at > ../../cpp/src/qpid/sys/Timer.cpp:139 > #4 0x2af116f4f7cc in runRunnable (p=0x1accd4b0) at > ../../cpp/src/qpid/sys/posix/Thread.cpp:35 > #5 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 > #6 0x003da34d3c2d in clone () from /lib64/libc.so.6 > Thread 9 (Thread 0x4217c940 (LWP 2353)): > #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 > #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at > ../../cpp/include/qpid/sys/posix/Mutex.h:116 > #4 0x2af1169651e6 in ScopedLock (this=0x4217bd70, l...@0x2af11730c360) > at ../../cpp/include/qpid/sys/Mutex.h:33 > #5 0x2af116f5c29a in > qpid::sys::DeletionManager::AllThreadsStatuses::delThreadStatus > (this=0x2af11730c360, t=0x1acd4d00) > at ../../cpp/src/qpid/sys/DeletionManager.h:148 > #6 0x2af116f5c340 in > qpid::sys::DeletionManager::destroyThreadState > () at ../../cpp/src/qpid/sys/DeletionManager.h:83 > #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at > ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 > #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at > ../../cpp/src/qpid/sys/Dispatcher.cpp:37 > #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at > ../../cpp/src/qpid/sys/posix/Thread.cpp:35 > #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 > #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 > Thread 8 (Thread 0x42b7d940 (LWP 2354)): > #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 > #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at > ../../cpp/include/qpid/sys/posix/Mutex.h:116 > #4 0x2af1169651e6 in ScopedLock (this=0x42b7cd70, l...@0x2af11730c360) > at ../../cpp/include/qpid/sys/Mutex.h:33 > #5 0x2af116f5c29a in > qpid::sys::DeletionManager::AllThreadsStatuses::delThreadStatus > (this=0x2af11730c360, t=0x1acd6160) > at ../../cpp/src/qpid/sys/DeletionManager.h:148 > #6 0x2af116f5c340 in > qpid::sys::DeletionManager::destroyThreadState > () at ../../cpp/src/qpid/sys/DeletionManager.h:83 > #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at > ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 > #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at > ../../cpp/src/qpid/sys/Dispatcher.cpp:37 > #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at > ../../cpp/src/qpid/sys/posix/Thread.cpp:35 > #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 > #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 > Thread 7 (Thread 0x4357e940 (LWP 2355)): > #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 > #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x1acd4bc0) at > ../../cpp/include/qpid/sys/posix/Mutex.h:116 > #4 0x2af11696
[jira] Updated: (QPID-2256) cluster_test hangs with theads deadlocked on mutex in DeletionManager.
[ https://issues.apache.org/jira/browse/QPID-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-2256: -- Affects Version/s: (was: 0.5) 0.6 > cluster_test hangs with theads deadlocked on mutex in DeletionManager. > -- > > Key: QPID-2256 > URL: https://issues.apache.org/jira/browse/QPID-2256 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.6 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Blocker > Fix For: 0.6 > > > Running cluster_test in a loop will fairly quickly result in a deadlock. The > test is blocked waiting for a child broker to exit. The broker appears > deadlocked around a mutex in DeletionManager, here are the stack traces of > the deadlocked broker: > Thread 10 (Thread 0x414b2940 (LWP 2351)): > #0 0x003da400af70 in pthread_cond_timedwait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x2af11703c21d in qpid::sys::Condition::wait (this=0x1accd4e0, > mut...@0x1accd4b8, absoluteti...@0x1acccae0) at > ../../cpp/include/qpid/sys/posix/Condition.h:69 > #2 0x2af11703c48b in qpid::sys::Monitor::wait (this=0x1accd4b8, > absoluteti...@0x1acccae0) at ../../cpp/include/qpid/sys/Monitor.h:45 > #3 0x2af1170396ac in qpid::sys::Timer::run (this=0x1accd4b0) at > ../../cpp/src/qpid/sys/Timer.cpp:139 > #4 0x2af116f4f7cc in runRunnable (p=0x1accd4b0) at > ../../cpp/src/qpid/sys/posix/Thread.cpp:35 > #5 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 > #6 0x003da34d3c2d in clone () from /lib64/libc.so.6 > Thread 9 (Thread 0x4217c940 (LWP 2353)): > #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 > #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at > ../../cpp/include/qpid/sys/posix/Mutex.h:116 > #4 0x2af1169651e6 in ScopedLock (this=0x4217bd70, l...@0x2af11730c360) > at ../../cpp/include/qpid/sys/Mutex.h:33 > #5 0x2af116f5c29a in > qpid::sys::DeletionManager::AllThreadsStatuses::delThreadStatus > (this=0x2af11730c360, t=0x1acd4d00) > at ../../cpp/src/qpid/sys/DeletionManager.h:148 > #6 0x2af116f5c340 in > qpid::sys::DeletionManager::destroyThreadState > () at ../../cpp/src/qpid/sys/DeletionManager.h:83 > #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at > ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 > #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at > ../../cpp/src/qpid/sys/Dispatcher.cpp:37 > #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at > ../../cpp/src/qpid/sys/posix/Thread.cpp:35 > #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 > #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 > Thread 8 (Thread 0x42b7d940 (LWP 2354)): > #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 > #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at > ../../cpp/include/qpid/sys/posix/Mutex.h:116 > #4 0x2af1169651e6 in ScopedLock (this=0x42b7cd70, l...@0x2af11730c360) > at ../../cpp/include/qpid/sys/Mutex.h:33 > #5 0x2af116f5c29a in > qpid::sys::DeletionManager::AllThreadsStatuses::delThreadStatus > (this=0x2af11730c360, t=0x1acd6160) > at ../../cpp/src/qpid/sys/DeletionManager.h:148 > #6 0x2af116f5c340 in > qpid::sys::DeletionManager::destroyThreadState > () at ../../cpp/src/qpid/sys/DeletionManager.h:83 > #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at > ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 > #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at > ../../cpp/src/qpid/sys/Dispatcher.cpp:37 > #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at > ../../cpp/src/qpid/sys/posix/Thread.cpp:35 > #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 > #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 > Thread 7 (Thread 0x4357e940 (LWP 2355)): > #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 > #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x1acd4bc0) at > ../../cpp/include/qpid/sys/posix/Mutex.h:116 > #4 0x2af1169651e6 in ScopedLock (this=0x4357da30, l...@0x1acd4bc0) at > ../../cpp/include/qpid/sys/Mutex.h:33 > #5 0x2af116f5b162
[jira] Commented: (QPID-2256) cluster_test hangs with theads deadlocked on mutex in DeletionManager.
[ https://issues.apache.org/jira/browse/QPID-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788257#action_12788257 ] Andrew Stitcher commented on QPID-2256: --- This must be a bug iin 0.6 as the code doesn't exist in 0.5 > cluster_test hangs with theads deadlocked on mutex in DeletionManager. > -- > > Key: QPID-2256 > URL: https://issues.apache.org/jira/browse/QPID-2256 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.6 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Blocker > Fix For: 0.6 > > > Running cluster_test in a loop will fairly quickly result in a deadlock. The > test is blocked waiting for a child broker to exit. The broker appears > deadlocked around a mutex in DeletionManager, here are the stack traces of > the deadlocked broker: > Thread 10 (Thread 0x414b2940 (LWP 2351)): > #0 0x003da400af70 in pthread_cond_timedwait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x2af11703c21d in qpid::sys::Condition::wait (this=0x1accd4e0, > mut...@0x1accd4b8, absoluteti...@0x1acccae0) at > ../../cpp/include/qpid/sys/posix/Condition.h:69 > #2 0x2af11703c48b in qpid::sys::Monitor::wait (this=0x1accd4b8, > absoluteti...@0x1acccae0) at ../../cpp/include/qpid/sys/Monitor.h:45 > #3 0x2af1170396ac in qpid::sys::Timer::run (this=0x1accd4b0) at > ../../cpp/src/qpid/sys/Timer.cpp:139 > #4 0x2af116f4f7cc in runRunnable (p=0x1accd4b0) at > ../../cpp/src/qpid/sys/posix/Thread.cpp:35 > #5 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 > #6 0x003da34d3c2d in clone () from /lib64/libc.so.6 > Thread 9 (Thread 0x4217c940 (LWP 2353)): > #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 > #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at > ../../cpp/include/qpid/sys/posix/Mutex.h:116 > #4 0x2af1169651e6 in ScopedLock (this=0x4217bd70, l...@0x2af11730c360) > at ../../cpp/include/qpid/sys/Mutex.h:33 > #5 0x2af116f5c29a in > qpid::sys::DeletionManager::AllThreadsStatuses::delThreadStatus > (this=0x2af11730c360, t=0x1acd4d00) > at ../../cpp/src/qpid/sys/DeletionManager.h:148 > #6 0x2af116f5c340 in > qpid::sys::DeletionManager::destroyThreadState > () at ../../cpp/src/qpid/sys/DeletionManager.h:83 > #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at > ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 > #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at > ../../cpp/src/qpid/sys/Dispatcher.cpp:37 > #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at > ../../cpp/src/qpid/sys/posix/Thread.cpp:35 > #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 > #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 > Thread 8 (Thread 0x42b7d940 (LWP 2354)): > #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 > #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at > ../../cpp/include/qpid/sys/posix/Mutex.h:116 > #4 0x2af1169651e6 in ScopedLock (this=0x42b7cd70, l...@0x2af11730c360) > at ../../cpp/include/qpid/sys/Mutex.h:33 > #5 0x2af116f5c29a in > qpid::sys::DeletionManager::AllThreadsStatuses::delThreadStatus > (this=0x2af11730c360, t=0x1acd6160) > at ../../cpp/src/qpid/sys/DeletionManager.h:148 > #6 0x2af116f5c340 in > qpid::sys::DeletionManager::destroyThreadState > () at ../../cpp/src/qpid/sys/DeletionManager.h:83 > #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at > ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 > #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at > ../../cpp/src/qpid/sys/Dispatcher.cpp:37 > #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at > ../../cpp/src/qpid/sys/posix/Thread.cpp:35 > #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 > #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 > Thread 7 (Thread 0x4357e940 (LWP 2355)): > #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 > #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x1acd4bc0) at > ../../cpp/include/qpid/sys/posix/Mutex.h:116 > #4 0x2af1169651e6 in ScopedLock (this=0x4357da30, l...@0x1acd4bc0) at > ../../cpp/in
RE: C++ broker: LockFile and shutdown (eliminating pid_t)
On Tue, 2009-12-08 at 18:25 -0500, Steve Huston wrote: > Hi Andrew, > > > I'm looking at QPID-1951: > > > > Eliminating ssize_t is trivial. > > Ok. > > > pid_t is used in a few more places though. However it is only used > in > > connection with LockFile. Either internally in Lockfile or to > > communicate a pid out of LockFile so that the process can be > > signalled. > > The other things the pid is used for are: It's not using the pid that is a problem per se it's using the type pid_t. So if you are using a DWORD type coming from GetCurrentProcessId() then this is not an issue. Also using pid_t in purely posix code isn't an issue as the windows code never sees it. The issue is using pid_t in the platform independent code. > > - print it to cout (Windows, posix) > - use it to open a handle to the broker process (Windows) Ah yes, I see that now - it looks like it would be encapsulatable though or replaced with another event, as it's being used not for signalling but to detect process exit. > > > It seems to me that the entire LockFile class could be better > factored > > to eliminate passing non portable process ids around by delegating > > signalling the other process to the LockFile class itself. I would > > change the name to something else at that point > > (suggestions?). In that > > case the lockfile itself becomes just an internal part of the > > signalling > > mechanism. > > > > Following in that direction it looks to me like for Windows at least > > doing this allows you to entirely replace the lock file > > itself with the named event that is already being used. > > No, the pid is still needed to get a handle to the process that's > being signalled. As above actually not for the signalling itself though. > > > Steve, Alan (as you are both mostly responsible for these > > implementations) is there anything I'm missing here or is this a > good > > direction? > > It seems the pid is still needed; maybe using a qpid::pid_t type would > be easier? Probably easier, but not necessarily better! I'll fiddle around a bit and see if I can get something simple enough. Andrew > > -Steve > - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Blocker for 0.6 release
I think this is a blocker for the release. I'm looking into it. It does not appear to be a cluster-specific problem although cluster_test is the only way I know to reproduce it at this point. https://issues.apache.org/jira/browse/QPID-2256 - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2256) cluster_test hangs with theads deadlocked on mutex in DeletionManager.
cluster_test hangs with theads deadlocked on mutex in DeletionManager.
--
Key: QPID-2256
URL: https://issues.apache.org/jira/browse/QPID-2256
Project: Qpid
Issue Type: Bug
Components: C++ Broker
Affects Versions: 0.5
Reporter: Alan Conway
Assignee: Alan Conway
Priority: Blocker
Fix For: 0.6
Running cluster_test in a loop will fairly quickly result in a deadlock. The
test is blocked waiting for a child broker to exit. The broker appears
deadlocked around a mutex in DeletionManager, here are the stack traces of the
deadlocked broker:
Thread 10 (Thread 0x414b2940 (LWP 2351)):
#0 0x003da400af70 in pthread_cond_timedwait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x2af11703c21d in qpid::sys::Condition::wait (this=0x1accd4e0,
mut...@0x1accd4b8, absoluteti...@0x1acccae0) at
../../cpp/include/qpid/sys/posix/Condition.h:69
#2 0x2af11703c48b in qpid::sys::Monitor::wait (this=0x1accd4b8,
absoluteti...@0x1acccae0) at ../../cpp/include/qpid/sys/Monitor.h:45
#3 0x2af1170396ac in qpid::sys::Timer::run (this=0x1accd4b0) at
../../cpp/src/qpid/sys/Timer.cpp:139
#4 0x2af116f4f7cc in runRunnable (p=0x1accd4b0) at
../../cpp/src/qpid/sys/posix/Thread.cpp:35
#5 0x003da4006617 in start_thread () from /lib64/libpthread.so.0
#6 0x003da34d3c2d in clone () from /lib64/libc.so.6
Thread 9 (Thread 0x4217c940 (LWP 2353)):
#0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0
#2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at
../../cpp/include/qpid/sys/posix/Mutex.h:116
#4 0x2af1169651e6 in ScopedLock (this=0x4217bd70, l...@0x2af11730c360) at
../../cpp/include/qpid/sys/Mutex.h:33
#5 0x2af116f5c29a in
qpid::sys::DeletionManager::AllThreadsStatuses::delThreadStatus
(this=0x2af11730c360, t=0x1acd4d00)
at ../../cpp/src/qpid/sys/DeletionManager.h:148
#6 0x2af116f5c340 in
qpid::sys::DeletionManager::destroyThreadState
() at ../../cpp/src/qpid/sys/DeletionManager.h:83
#7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at
../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488
#8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at
../../cpp/src/qpid/sys/Dispatcher.cpp:37
#9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at
../../cpp/src/qpid/sys/posix/Thread.cpp:35
#10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0
#11 0x003da34d3c2d in clone () from /lib64/libc.so.6
Thread 8 (Thread 0x42b7d940 (LWP 2354)):
#0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0
#2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at
../../cpp/include/qpid/sys/posix/Mutex.h:116
#4 0x2af1169651e6 in ScopedLock (this=0x42b7cd70, l...@0x2af11730c360) at
../../cpp/include/qpid/sys/Mutex.h:33
#5 0x2af116f5c29a in
qpid::sys::DeletionManager::AllThreadsStatuses::delThreadStatus
(this=0x2af11730c360, t=0x1acd6160)
at ../../cpp/src/qpid/sys/DeletionManager.h:148
#6 0x2af116f5c340 in
qpid::sys::DeletionManager::destroyThreadState
() at ../../cpp/src/qpid/sys/DeletionManager.h:83
#7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at
../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488
#8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at
../../cpp/src/qpid/sys/Dispatcher.cpp:37
#9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at
../../cpp/src/qpid/sys/posix/Thread.cpp:35
#10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0
#11 0x003da34d3c2d in clone () from /lib64/libc.so.6
Thread 7 (Thread 0x4357e940 (LWP 2355)):
#0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0
#2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x1acd4bc0) at
../../cpp/include/qpid/sys/posix/Mutex.h:116
#4 0x2af1169651e6 in ScopedLock (this=0x4357da30, l...@0x1acd4bc0) at
../../cpp/include/qpid/sys/Mutex.h:33
#5 0x2af116f5b162 in
qpid::sys::DeletionManager::AllThreadsStatuses::handleAdder::operator()
(this=0x4357dad0, ptr=0x1acd4bc0)
at ../../cpp/src/qpid/sys/DeletionManager.h:128
#6 0x2af116f5b1d3 in
std::for_each<__gnu_cxx::__normal_iterator::ThreadStatus**,
std::vector::ThreadStatus*,
std::allocator::ThreadStatus*>
> >,
qpid::sys::DeletionManager::AllThreadsStatuses::handleAdder>
(__first={_M_current = 0x1acd6410}, __las
Re: Documentation (was Re: Feedback from Qpid users)
On Wed, Dec 9, 2009 at 1:57 PM, Joshua Kramer wrote: > > Rajith, Everyone: > >> 1. The Qpid documentation is incomplete, disorganized and often >> 2. The documentation does not reflect the code. Especially >> 3. The clients (non JMS) are difficult to use without reasonable >> knowledge about AMQP. > > I had an article on QPid in the November issue of Linux Journal. Thankfully, > the author's contract for LJ permits me to use the article in project > documentation after the magazine has been out for a month. > > My article specifically addresses how to set up a C++ broker and Python > clients and use them in several configurations (direct, pub-sub). I am more > than happy to contribute this. To whom should I send it to review for > inclusion in the docs? +1 Thanks for doing this and I hope you continue to help. Once you attach it to JIRA we could try to incorporate it into the documentation that we are trying to put in place in svn. Jonathan is currently trying to organize this effort. Once the structure is put in place you could directly submit patches against the doc-book source. Currently there is a lot of gaps and contributions are most welcome. However I'd wait until Jonathan gets a chance to take stock of the existing docs and port it to the new format. That way we could ensure no effort is duplicated. > Thanks, > -Joshua Kramer > > > > -- > > - > http://www.globalherald.net/jb01 > GlobalHerald.NET, the Smarter Social Network! (tm) > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Release artifacts
On Wed, Dec 9, 2009 at 12:30 PM, Robert Godfrey wrote: > 2009/12/9 Rafael Schloming > >> Robbie Gemmell wrote: >> >>> Hi all, >>> >>> Now that we have entered another release phase I think it would be a good >>> time to discuss the release artifacts. I would like to see 0.6 ship with >>> some updates to the artifacts we produce to make things more useful and >>> obvious for our users. >>> >> >> I think it's a bit late for 0.6, if I understand the timeline correctly. >> >> >> The "Java broker, client, and tools" multi-component package appears to be >>> just a copy of the etc/ lib/ and bin/ directories from the qpid/java/build/ >>> dir after performing a build and this makes it quite messy. A lot of test >>> configuration files are left in the etc/ dir and there are loads of jars in >>> the lib/ dir, which make it very hard to know which is being used where or >>> allow splitting them up easily. You also end up with jars that just aren't >>> intended to be used from there (eg the eclipse-plugin used in the JMX >>> Management Console releases). We have single component packages for the Java >>> broker, client, and management tools so if we want a multi-component package >>> including any of these I think we should simply bundle those up instead of >>> just tarring the build folder and mashing everything together. >>> >> >> I sort of disagree with this. There is a "philosophy" behind using the >> "just a copy" approach. The benefit is that we can eliminate a whole class >> of bugs resulting from complex transformations necessary to turn the build >> artifacts into release artifacts. Not to mention it is easier for us to >> reproducer user issues if dev and user environments are as similar as >> possible. >> >> That said I'm fine cleaning up the release artifacts and what not, I'm just >> -1 on doing it by introducing complex transformations between build and >> release artifacts. If we want the release artifacts to look different we >> should make the build artifacts look different. >> >> As I've said before I'm happy to help with this, but we sort of need to >> figure out what we want things to look like first, and IMHO such an effort >> should also include making release artifacts more consistent across the >> whole project. >> >> > I think this is the key point - we need to work out how our build and > release artefacts look; since what we have today is clearly unsatisfactory. > > If there are quick, non-risky, changes that we could put in place for 0.6 > that are universally acknowledged as a step in the right direction, I > wouldn't necessarily be against them - however I don't think we want to > embark on anything that will negatively impact a 0.6 release date at this > stage. I am hugely +1 in doing this work before 0.7 (it's clearly a > necessity for us if we ever want to get to a 1.0 release) Totally agree here. I think for the 0.7 release we definitely need to consider sorting out our documentation and release artifacts a top priority. I also agree that we need to have a consistent story across all our components than a per language approach. >> >> Another result of the above is that QMan is shipped in the Java >>> multi-component bundle despite the fact it is only useful if you have a C++ >>> broker. I realise it is written in Java, but those packages don't seem to me >>> like they should necessarily be language specific. If anything I would say >>> that QMan should surely ship in the multi-component bundle along with the >>> items it can actually be used with (ie the C++ broker and client bundle), or >>> just be made available standalone (which it already is). Users aren't >>> necessarily going to expect they need to download both multi-component >>> packages to make use of everything contained in one of them, and as >>> mentioned above, splitting QMan alone out of the java multi-component bundle >>> would be a bit hideous and non obvious anyway. >>> >>> I would also like to see us tagging the source-only release artifacts with >>> 'src', ie the C++ and the "full" release artifact that is just a copy of the >>> entire repo. It isn't exactly helpful for a user to download the 50MB file >>> then find out what they are looking for isn't actually in there. >>> >> >> I also think it's a shame that our artifacts look like they come from >> entirely different projects. Even little things like readme capitalization, >> general directory layout, etc is completely different from artifact to >> artifact, and this is even after the release script hacks to rearchive stuff >> to make things a bit more consistent. >> >> > Agree again completely. We have a lot of work to do - which we should do as > a matter of priority - in sorting out our artefacts to present a more > consistent appearance across the project. > > -- Rob > > >> --Rafael >> >> >> >> - >> Apache Qpid - AMQP Messaging Implementation >> Project: http://qpid.apache.org
RE: Release artifacts
I can see what you are saying and thus agree that it would be beneficial for the build system in general to always generate the release style artifacts. However I don't see that this means we shouldn't use what we have at our disposal now in order to give our users a better experience than we currently are. Robbie > -Original Message- > From: Rafael Schloming [mailto:rafa...@redhat.com] > Sent: 09 December 2009 17:45 > To: dev@qpid.apache.org > Subject: Re: Release artifacts > > Robbie Gemmell wrote: > > I'm not meaning to suggest doing any complex transformations, rather > using what is already there. We have single-component packages that we > already release separately for all these items, I'm just talking about > whacking the relevant ones in a new tar and calling job done, instead > of having a mashup that contains things people don't want or that can't > even be used together. > > My issue with this is that the single-component packages weren't done > according to the "philosophy" of the build system, and as such the > process for producing component release artifacts diverges somewhat > significantly from the process for producing build artifacts. So while > what you suggest might not involve additional complex transformations, > it does result in something that I would prefer to avoid, which is two > separate systems, one for producing build artifacts, and the other for > producing release artifacts. > > --Rafael > > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2254) Documentation: Review attached article for inclusion in documentation
[ https://issues.apache.org/jira/browse/QPID-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joshua Kramer updated QPID-2254: Attachment: Figure1-v2.png > Documentation: Review attached article for inclusion in documentation > - > > Key: QPID-2254 > URL: https://issues.apache.org/jira/browse/QPID-2254 > Project: Qpid > Issue Type: Task > Components: C++ Broker, Python Client, Qpid Examples >Affects Versions: M4, 0.5 > Environment: RHEL / CentOS 5.4 >Reporter: Joshua Kramer > Attachments: AMQP-Article-Final.txt, Figure1-v2.pdf, Figure1-v2.png, > Listing1.py, Listing2.py, Listing3.py, Listing4.py > > > For an improvement to the documentation, I have attached my article that > appeared in November 2009 Linux Journal. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2254) Documentation: Review attached article for inclusion in documentation
[ https://issues.apache.org/jira/browse/QPID-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joshua Kramer updated QPID-2254: Attachment: Figure1-v2.pdf Listing4.py Listing3.py > Documentation: Review attached article for inclusion in documentation > - > > Key: QPID-2254 > URL: https://issues.apache.org/jira/browse/QPID-2254 > Project: Qpid > Issue Type: Task > Components: C++ Broker, Python Client, Qpid Examples >Affects Versions: M4, 0.5 > Environment: RHEL / CentOS 5.4 >Reporter: Joshua Kramer > Attachments: AMQP-Article-Final.txt, Figure1-v2.pdf, Listing1.py, > Listing2.py, Listing3.py, Listing4.py > > > For an improvement to the documentation, I have attached my article that > appeared in November 2009 Linux Journal. -- 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-2255) new API doesn't properly parse mime types when interpreting message content
new API doesn't properly parse mime types when interpreting message content --- Key: QPID-2255 URL: https://issues.apache.org/jira/browse/QPID-2255 Project: Qpid Issue Type: Bug Components: Python Client Affects Versions: 0.6 Reporter: Rafael H. Schloming Assignee: Rafael H. Schloming the python impl of the new API just does a simple lookup on mime types rather than parsing them properly, e.g. it should correctly handle. "text/plain" vs "text/plain; charset=utf8" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2254) Documentation: Review attached article for inclusion in documentation
[ https://issues.apache.org/jira/browse/QPID-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joshua Kramer updated QPID-2254: Attachment: Listing2.py Listing1.py AMQP-Article-Final.txt > Documentation: Review attached article for inclusion in documentation > - > > Key: QPID-2254 > URL: https://issues.apache.org/jira/browse/QPID-2254 > Project: Qpid > Issue Type: Task > Components: C++ Broker, Python Client, Qpid Examples >Affects Versions: M4, 0.5 > Environment: RHEL / CentOS 5.4 >Reporter: Joshua Kramer > Attachments: AMQP-Article-Final.txt, Listing1.py, Listing2.py > > > For an improvement to the documentation, I have attached my article that > appeared in November 2009 Linux Journal. -- 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-2254) Documentation: Review attached article for inclusion in documentation
Documentation: Review attached article for inclusion in documentation - Key: QPID-2254 URL: https://issues.apache.org/jira/browse/QPID-2254 Project: Qpid Issue Type: Task Components: C++ Broker, Python Client, Qpid Examples Affects Versions: 0.5, M4 Environment: RHEL / CentOS 5.4 Reporter: Joshua Kramer For an improvement to the documentation, I have attached my article that appeared in November 2009 Linux Journal. -- 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: Release artifacts
Robbie Gemmell wrote: I'm not meaning to suggest doing any complex transformations, rather using what is already there. We have single-component packages that we already release separately for all these items, I'm just talking about whacking the relevant ones in a new tar and calling job done, instead of having a mashup that contains things people don't want or that can't even be used together. My issue with this is that the single-component packages weren't done according to the "philosophy" of the build system, and as such the process for producing component release artifacts diverges somewhat significantly from the process for producing build artifacts. So while what you suggest might not involve additional complex transformations, it does result in something that I would prefer to avoid, which is two separate systems, one for producing build artifacts, and the other for producing release artifacts. --Rafael - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Documentation (was Re: Feedback from Qpid users)
On 12/09/2009 01:57 PM, Joshua Kramer wrote: I had an article on QPid in the November issue of Linux Journal. Thankfully, the author's contract for LJ permits me to use the article in project documentation after the magazine has been out for a month. My article specifically addresses how to set up a C++ broker and Python clients and use them in several configurations (direct, pub-sub). I am more than happy to contribute this. To whom should I send it to review for inclusion in the docs? You can attach them to a JIRA. You could also send them to me, but it's better if everyone sees them. Jonathan - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Release artifacts
2009/12/9 Rafael Schloming > Robbie Gemmell wrote: > >> Hi all, >> >> Now that we have entered another release phase I think it would be a good >> time to discuss the release artifacts. I would like to see 0.6 ship with >> some updates to the artifacts we produce to make things more useful and >> obvious for our users. >> > > I think it's a bit late for 0.6, if I understand the timeline correctly. > > > The "Java broker, client, and tools" multi-component package appears to be >> just a copy of the etc/ lib/ and bin/ directories from the qpid/java/build/ >> dir after performing a build and this makes it quite messy. A lot of test >> configuration files are left in the etc/ dir and there are loads of jars in >> the lib/ dir, which make it very hard to know which is being used where or >> allow splitting them up easily. You also end up with jars that just aren't >> intended to be used from there (eg the eclipse-plugin used in the JMX >> Management Console releases). We have single component packages for the Java >> broker, client, and management tools so if we want a multi-component package >> including any of these I think we should simply bundle those up instead of >> just tarring the build folder and mashing everything together. >> > > I sort of disagree with this. There is a "philosophy" behind using the > "just a copy" approach. The benefit is that we can eliminate a whole class > of bugs resulting from complex transformations necessary to turn the build > artifacts into release artifacts. Not to mention it is easier for us to > reproducer user issues if dev and user environments are as similar as > possible. > > That said I'm fine cleaning up the release artifacts and what not, I'm just > -1 on doing it by introducing complex transformations between build and > release artifacts. If we want the release artifacts to look different we > should make the build artifacts look different. > > As I've said before I'm happy to help with this, but we sort of need to > figure out what we want things to look like first, and IMHO such an effort > should also include making release artifacts more consistent across the > whole project. > > I think this is the key point - we need to work out how our build and release artefacts look; since what we have today is clearly unsatisfactory. If there are quick, non-risky, changes that we could put in place for 0.6 that are universally acknowledged as a step in the right direction, I wouldn't necessarily be against them - however I don't think we want to embark on anything that will negatively impact a 0.6 release date at this stage. I am hugely +1 in doing this work before 0.7 (it's clearly a necessity for us if we ever want to get to a 1.0 release) > > Another result of the above is that QMan is shipped in the Java >> multi-component bundle despite the fact it is only useful if you have a C++ >> broker. I realise it is written in Java, but those packages don't seem to me >> like they should necessarily be language specific. If anything I would say >> that QMan should surely ship in the multi-component bundle along with the >> items it can actually be used with (ie the C++ broker and client bundle), or >> just be made available standalone (which it already is). Users aren't >> necessarily going to expect they need to download both multi-component >> packages to make use of everything contained in one of them, and as >> mentioned above, splitting QMan alone out of the java multi-component bundle >> would be a bit hideous and non obvious anyway. >> >> I would also like to see us tagging the source-only release artifacts with >> 'src', ie the C++ and the "full" release artifact that is just a copy of the >> entire repo. It isn't exactly helpful for a user to download the 50MB file >> then find out what they are looking for isn't actually in there. >> > > I also think it's a shame that our artifacts look like they come from > entirely different projects. Even little things like readme capitalization, > general directory layout, etc is completely different from artifact to > artifact, and this is even after the release script hacks to rearchive stuff > to make things a bit more consistent. > > Agree again completely. We have a lot of work to do - which we should do as a matter of priority - in sorting out our artefacts to present a more consistent appearance across the project. -- Rob > --Rafael > > > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > >
RE: Release artifacts
I'm not meaning to suggest doing any complex transformations, rather using what is already there. We have single-component packages that we already release separately for all these items, I'm just talking about whacking the relevant ones in a new tar and calling job done, instead of having a mashup that contains things people don't want or that can't even be used together. Robbie > -Original Message- > From: Rafael Schloming [mailto:rafa...@redhat.com] > Sent: 09 December 2009 17:17 > To: dev@qpid.apache.org > Subject: Re: Release artifacts > > Robbie Gemmell wrote: > > Hi all, > > > > Now that we have entered another release phase I think it would be a > good time to discuss the release artifacts. I would like to see 0.6 > ship with some updates to the artifacts we produce to make things more > useful and obvious for our users. > > I think it's a bit late for 0.6, if I understand the timeline > correctly. > > > The "Java broker, client, and tools" multi-component package appears > to be just a copy of the etc/ lib/ and bin/ directories from the > qpid/java/build/ dir after performing a build and this makes it quite > messy. A lot of test configuration files are left in the etc/ dir and > there are loads of jars in the lib/ dir, which make it very hard to > know which is being used where or allow splitting them up easily. You > also end up with jars that just aren't intended to be used from there > (eg the eclipse-plugin used in the JMX Management Console releases). We > have single component packages for the Java broker, client, and > management tools so if we want a multi-component package including any > of these I think we should simply bundle those up instead of just > tarring the build folder and mashing everything together. > > I sort of disagree with this. There is a "philosophy" behind using the > "just a copy" approach. The benefit is that we can eliminate a whole > class of bugs resulting from complex transformations necessary to turn > the build artifacts into release artifacts. Not to mention it is easier > for us to reproducer user issues if dev and user environments are as > similar as possible. > > That said I'm fine cleaning up the release artifacts and what not, I'm > just -1 on doing it by introducing complex transformations between > build > and release artifacts. If we want the release artifacts to look > different we should make the build artifacts look different. > > As I've said before I'm happy to help with this, but we sort of need to > figure out what we want things to look like first, and IMHO such an > effort should also include making release artifacts more consistent > across the whole project. > > > Another result of the above is that QMan is shipped in the Java > multi-component bundle despite the fact it is only useful if you have a > C++ broker. I realise it is written in Java, but those packages don't > seem to me like they should necessarily be language specific. If > anything I would say that QMan should surely ship in the multi- > component bundle along with the items it can actually be used with (ie > the C++ broker and client bundle), or just be made available standalone > (which it already is). Users aren't necessarily going to expect they > need to download both multi-component packages to make use of > everything contained in one of them, and as mentioned above, splitting > QMan alone out of the java multi-component bundle would be a bit > hideous and non obvious anyway. > > > > I would also like to see us tagging the source-only release artifacts > with 'src', ie the C++ and the "full" release artifact that is just a > copy of the entire repo. It isn't exactly helpful for a user to > download the 50MB file then find out what they are looking for isn't > actually in there. > > I also think it's a shame that our artifacts look like they come from > entirely different projects. Even little things like readme > capitalization, general directory layout, etc is completely different > from artifact to artifact, and this is even after the release script > hacks to rearchive stuff to make things a bit more consistent. > > --Rafael > > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Documentation (was Re: Feedback from Qpid users)
Rajith, Everyone: 1. The Qpid documentation is incomplete, disorganized and often 2. The documentation does not reflect the code. Especially 3. The clients (non JMS) are difficult to use without reasonable knowledge about AMQP. I had an article on QPid in the November issue of Linux Journal. Thankfully, the author's contract for LJ permits me to use the article in project documentation after the magazine has been out for a month. My article specifically addresses how to set up a C++ broker and Python clients and use them in several configurations (direct, pub-sub). I am more than happy to contribute this. To whom should I send it to review for inclusion in the docs? Thanks, -Joshua Kramer -- - http://www.globalherald.net/jb01 GlobalHerald.NET, the Smarter Social Network! (tm) - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [VOTE] Committership Criteria
On Tue, Dec 8, 2009 at 7:34 PM, Rafael Schloming wrote: > [ ] Adopt the above statements as our official committership criteria. +1 - Aidan -- Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org "A witty saying proves nothing" - Voltaire - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Release artifacts
Robbie Gemmell wrote: Hi all, Now that we have entered another release phase I think it would be a good time to discuss the release artifacts. I would like to see 0.6 ship with some updates to the artifacts we produce to make things more useful and obvious for our users. I think it's a bit late for 0.6, if I understand the timeline correctly. The "Java broker, client, and tools" multi-component package appears to be just a copy of the etc/ lib/ and bin/ directories from the qpid/java/build/ dir after performing a build and this makes it quite messy. A lot of test configuration files are left in the etc/ dir and there are loads of jars in the lib/ dir, which make it very hard to know which is being used where or allow splitting them up easily. You also end up with jars that just aren't intended to be used from there (eg the eclipse-plugin used in the JMX Management Console releases). We have single component packages for the Java broker, client, and management tools so if we want a multi-component package including any of these I think we should simply bundle those up instead of just tarring the build folder and mashing everything together. I sort of disagree with this. There is a "philosophy" behind using the "just a copy" approach. The benefit is that we can eliminate a whole class of bugs resulting from complex transformations necessary to turn the build artifacts into release artifacts. Not to mention it is easier for us to reproducer user issues if dev and user environments are as similar as possible. That said I'm fine cleaning up the release artifacts and what not, I'm just -1 on doing it by introducing complex transformations between build and release artifacts. If we want the release artifacts to look different we should make the build artifacts look different. As I've said before I'm happy to help with this, but we sort of need to figure out what we want things to look like first, and IMHO such an effort should also include making release artifacts more consistent across the whole project. Another result of the above is that QMan is shipped in the Java multi-component bundle despite the fact it is only useful if you have a C++ broker. I realise it is written in Java, but those packages don't seem to me like they should necessarily be language specific. If anything I would say that QMan should surely ship in the multi-component bundle along with the items it can actually be used with (ie the C++ broker and client bundle), or just be made available standalone (which it already is). Users aren't necessarily going to expect they need to download both multi-component packages to make use of everything contained in one of them, and as mentioned above, splitting QMan alone out of the java multi-component bundle would be a bit hideous and non obvious anyway. I would also like to see us tagging the source-only release artifacts with 'src', ie the C++ and the "full" release artifact that is just a copy of the entire repo. It isn't exactly helpful for a user to download the 50MB file then find out what they are looking for isn't actually in there. I also think it's a shame that our artifacts look like they come from entirely different projects. Even little things like readme capitalization, general directory layout, etc is completely different from artifact to artifact, and this is even after the release script hacks to rearchive stuff to make things a bit more consistent. --Rafael - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Feedback from Qpid users
Hi, During the FUDCon in Toronto last weekend, I was pleasantly surprised to see that Qpid was used in several upstream projects connected to the Fedora community. However the feedback from the folks I spoke to shows that we could certainly do better to make the end user experience work. On the bright side it seems we are on track to resolve these issues. The top 3 complains I heard from people. 1. The Qpid documentation is incomplete, disorganized and often lacking crucial information completely. (Ex. there is no guide for SASL setup in the c++ broker) 2. The documentation does not reflect the code. Especially documentation for clients was poor. 3. The clients (non JMS) are difficult to use without reasonable knowledge about AMQP. I think items 1 & 2 will be addressed to a reasonable extent with re-organizing our website and having version controlled documentation in svn. Item 3 would be addressed by our current effort around high level client APIs - infact many said that is what they need. Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: First Qpid 0.6 Beta Release available for download and testing
The single component package for QMan is not currently being created (although I seem to recall this happening with 0.5 as well). I think it uses a slightly non standard target to build the package just now, so ill see if I can modify it to be the same as the others and then the release script just needs updated to perform the copy. Robbie > -Original Message- > From: Andrew Stitcher [mailto:astitc...@redhat.com] > Sent: 03 December 2009 00:54 > To: dev@qpid.apache.org > Subject: First Qpid 0.6 Beta Release available for download and testing > > Apologies for the long message, but there actually is a fair bit to > say: > > I've uploaded the artifacts for a 0.6 beta release to qpid.apache.org: > > http://qpid.apache.org/dist/qpid-0.6beta1/ > > Please download and test this release. No, really, please download and > at least look at it. > > I've called it a beta because, it seems to me in the area that I know > (C > ++) and in the currently outstanding bugs it seems very usable. > > I plan that every one should give this a good beating for 1-2 weeks and > then I'll spin a release candidate, or if there are many problems found > and fixed a beta2. > > So all being well I'd like to vote on releasing 0.6 in a couple of > weeks. > > --- > > The status of this beta: > > My testing has been building the C++ tar source under various linux > platforms (using this release or very slightly earlier ones). > Essentially "configure; make check". > > Fedora 11/Fedora 12 (these both tested with the same results): > > Autotools build is fine including all broker modules. It doesn't seem > that the build as it stands in the C++ source release builds the qmf > bindings. > > Cmake build is mostly fine - however the clustering module doesn't > build > due to a complication of recent versions of boost. And r886259 breaks > building the clustering tests (due to missing the new > tests/cluster.cmake from EXTRA_DIST) > > Red Hat Enterprise Linux 5: > > Autotools builds fine. > > Cmake builds fine (but this was a slightly earlier release and this > would have been broken by r886259 as above). > > Debian 5 (lenny). > > Neither the clustering module nor the XML module have their necessary > prerequisites so can't be built here. > > Given this both autotools and cmake builds were fine. > > --- > > Overall Release Status: > > I've put up a page for the release on the wiki: > > http://cwiki.apache.org/confluence/display/qpid/0.6+Release > > (don't use the mirror on qpid.apache.org as it won't have the > dynamically updated bug list) > > Please edit the release page to add your understanding to it - it's a > little biased to the areas that I know about presently. > > One area that needs attention is the Release notes, I appeal to you to > add any release notes to that wiki page and I will turn them into > something to put in the release itself. Otherwise the only release > notes > will be for the C++ code and whatever I can get from the 0.6 fixed > bugs. > > --- > > Deficiencies: > > I've removed the separate dotnet package from the release as it doesn't > build for me using the release script. More about this separately. > > I've not packaged the wcf code separately as I've no idea how it should > look and I doubt I could build it under Linux anyway. > > I'm concerned there appear to be 5 13Mb eclipse plugins labelled for > various platforms - is this really necessary - it certainly took a long > time to upload and constitutes a large amount of space. > > --- > > At this point I suggest that any bugs important enough to be fixed > before the 0.6 release should be tagged with "Fix version" 0.6 and be a > blocker or critical. > > So if you find an issue that must be fixed before release then put it > in > Jira like this. > > Conversely if you know of a bug that is in this state that can be > resolved then resolve it poste haste. > > I will assume that as long as there *any* bugs like this 0.6 release is > blocked. > > Regards > > Andrew > > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-2253) Cluster node shutsdown with inconsistent error
[ https://issues.apache.org/jira/browse/QPID-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved QPID-2253. --- Resolution: Fixed Fixed in r74 > Cluster node shutsdown with inconsistent error > --- > > Key: QPID-2253 > URL: https://issues.apache.org/jira/browse/QPID-2253 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.5 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.6 > > > Description of problem: > When running the "test_failover" test case in the qpid-python-testkit > framework > where cluster nodes are shutdown and new members are added, a new node just > joined encounters an error of the form "confirmed N but only sent N-1" which > is > only raised on the said member causing it to shut down as inconsistent. > Version-Release number of selected component (if applicable): > qpid trunk > How reproducible: > Always > Steps to Reproduce: > 1. checkout svn > 2. build c++ broker and cluster module > 3. go to java/testkit/bin and run ./qpid-python-testkit > Actual results: > cluster2-5: 2009-12-04 14:44:35 notice cluster(192.168.1.103:14491 READY) > caught up, active cluster member. > cluster2-5: 2009-12-04 14:44:36 error Execution exception: invalid-argument: > anonymous.e3a66a8d-330d-47c2-b96d-bb0b1315248b: confirmed < (2+0) but only > sent > < (1+0) (qpid/SessionState.cpp:151) > cluster2-5: 2009-12-04 14:44:36 critical cluster(192.168.1.103:14491 > READY/error) local error 599 did not occur on member 192.168.1.103:14453: > invalid-argument: anonymous.e3a66a8d-330d-47c2-b96d-bb0b1315248b: confirmed < > (2+0) but only sent < (1+0) (qpid/SessionState.cpp:151) > cluster2-5: 2009-12-04 14:44:36 error Error delivering frames: local error did > not occur on all cluster members : invalid-argument: > anonymous.e3a66a8d-330d-47c2-b96d-bb0b1315248b: confirmed < (2+0) but only > sent > < (1+0) (qpid/SessionState.cpp:151) (qpid/cluster/ErrorCheck.cpp:89) > cluster2-5: 2009-12-04 14:44:36 notice cluster(192.168.1.103:14491 LEFT/error) > leaving cluster cluster2-helaya:13958 > cluster2-5: 2009-12-04 14:44:36 notice Shut down > Expected results: > There should not be any inconsistent errors. -- 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: [VOTE] Committership Criteria
On 12/09/2009 04:44 PM, Robert Godfrey wrote: 2009/12/9 Gordon Sim On 12/09/2009 03:06 PM, Gordon Sim wrote: On 12/08/2009 07:34 PM, Rafael Schloming wrote: As there have been no comments or questions on the discussion thread, I'm going to move this to a vote: Sorry for jumping in late here, I was away on holiday when the mail was first sent. Qualities we look for: - A candidate must demonstrate an understanding of how our project is structured and how we work. Could we make this a bit more concrete/specific? For me the key to how we work is a collaborative, consensus based approach to development. What is meant by project structure here? A knowledge of the different components and how they are intended to work as a whole? Or an appreciation of the individuals that work on particular areas (i.e. the team structure)? Or something else? Just to be clear, I am not opposing the vote here. I'm just suggesting that by spelling out "how our project is structured and how we work" we cold make the list of qualities more precise. Defining how we work and how our project is structured is probably a separate document and a separate vote... I think some of the other threads recently have been moving us forward on those points, and I would like to see that work completed as soon as possible. It doesn't seem to me, however, to be a barrier to voting in the Committership Criteria that we have not yet formally defined these, since we may anyway change our structure and practice over time. Yes, that is fine by me. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Release artifacts
Hi all, Now that we have entered another release phase I think it would be a good time to discuss the release artifacts. I would like to see 0.6 ship with some updates to the artifacts we produce to make things more useful and obvious for our users. The "Java broker, client, and tools" multi-component package appears to be just a copy of the etc/ lib/ and bin/ directories from the qpid/java/build/ dir after performing a build and this makes it quite messy. A lot of test configuration files are left in the etc/ dir and there are loads of jars in the lib/ dir, which make it very hard to know which is being used where or allow splitting them up easily. You also end up with jars that just aren't intended to be used from there (eg the eclipse-plugin used in the JMX Management Console releases). We have single component packages for the Java broker, client, and management tools so if we want a multi-component package including any of these I think we should simply bundle those up instead of just tarring the build folder and mashing everything together. Another result of the above is that QMan is shipped in the Java multi-component bundle despite the fact it is only useful if you have a C++ broker. I realise it is written in Java, but those packages don't seem to me like they should necessarily be language specific. If anything I would say that QMan should surely ship in the multi-component bundle along with the items it can actually be used with (ie the C++ broker and client bundle), or just be made available standalone (which it already is). Users aren't necessarily going to expect they need to download both multi-component packages to make use of everything contained in one of them, and as mentioned above, splitting QMan alone out of the java multi-component bundle would be a bit hideous and non obvious anyway. I would also like to see us tagging the source-only release artifacts with 'src', ie the C++ and the "full" release artifact that is just a copy of the entire repo. It isn't exactly helpful for a user to download the 50MB file then find out what they are looking for isn't actually in there. Robbie - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [QMF] public github repo for QMFv2 api work
Ken I appreciate your effort in making the development process as open as possible. But I agree with Steve about the licensing issues. I think the safest option is to expose your work through a series of JIRA's. If we need to make the code available immediately and/or collaborate with others we could create a branch. You could work off the branch and then Ted could apply the patches as an when they are made available. Rajith On Wed, Dec 9, 2009 at 11:15 AM, Steve Huston wrote: > Hi Ken, > >> -Original Message- >> From: Ken Giusti [mailto:kgiu...@redhat.com] >> Sent: Wednesday, December 09, 2009 9:00 AM >> To: dev >> Subject: [QMF] public github repo for QMFv2 api work >> >> >> Hi all, >> >> Just fyi - I've set up a public git repo at github so I can >> develop the QMFv2 API code publicly. I've created this >> because I am not a committer, but I want this stuff available >> to all during development. >> >> git://github.com/kgiusti/qpid.git >> >> This repo is based on the apache qpid trunk repo on github. > > I was in a similar situation when I did the initial Windows port a > while back, and I went the git route too. I was advised by more senior > Apache people that it's not a good idea because it opens the door to > code getting in which hasn't been through the JIRA's "I license this > to Apache" check-off. If someone without a CLA drops code into your > git repo, then that goes into the svn repo, that's a big problem. > > FWIW, > > -Steve > > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [VOTE] Committership Criteria
2009/12/9 Gordon Sim > On 12/09/2009 03:06 PM, Gordon Sim wrote: > >> On 12/08/2009 07:34 PM, Rafael Schloming wrote: >> >>> As there have been no comments or questions on the discussion thread, >>> I'm going to move this to a vote: >>> >> >> Sorry for jumping in late here, I was away on holiday when the mail was >> first sent. >> >> Qualities we look for: >>> >>> - A candidate must demonstrate an understanding of how our project >>> is structured and how we work. >>> >> >> Could we make this a bit more concrete/specific? >> >> For me the key to how we work is a collaborative, consensus based >> approach to development. >> >> What is meant by project structure here? A knowledge of the different >> components and how they are intended to work as a whole? Or an >> appreciation of the individuals that work on particular areas (i.e. the >> team structure)? Or something else? >> > > Just to be clear, I am not opposing the vote here. I'm just suggesting that > by spelling out "how our project is structured and how we work" we cold make > the list of qualities more precise. > > Defining how we work and how our project is structured is probably a separate document and a separate vote... I think some of the other threads recently have been moving us forward on those points, and I would like to see that work completed as soon as possible. It doesn't seem to me, however, to be a barrier to voting in the Committership Criteria that we have not yet formally defined these, since we may anyway change our structure and practice over time. -- Rob > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > >
Re: [VOTE] Committership Criteria
On 12/09/2009 03:06 PM, Gordon Sim wrote: On 12/08/2009 07:34 PM, Rafael Schloming wrote: As there have been no comments or questions on the discussion thread, I'm going to move this to a vote: Sorry for jumping in late here, I was away on holiday when the mail was first sent. Qualities we look for: - A candidate must demonstrate an understanding of how our project is structured and how we work. Could we make this a bit more concrete/specific? For me the key to how we work is a collaborative, consensus based approach to development. What is meant by project structure here? A knowledge of the different components and how they are intended to work as a whole? Or an appreciation of the individuals that work on particular areas (i.e. the team structure)? Or something else? Just to be clear, I am not opposing the vote here. I'm just suggesting that by spelling out "how our project is structured and how we work" we cold make the list of qualities more precise. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: [VOTE] Committership Criteria
> -Original Message- > From: Rafael Schloming [mailto:rafa...@redhat.com] > Sent: 08 December 2009 19:34 > To: dev@qpid.apache.org > Subject: [VOTE] Committership Criteria > > As there have been no comments or questions on the discussion thread, > I'm going to move this to a vote: > > Qualities we look for: > >- A candidate must demonstrate an understanding of how our project > is structured and how we work. > >- A candidate must communicate openly about work planned/in- > progress. > >- A candidate must demonstrate expertise in a significant area of > the existing code base. > >- A candidate must demonstrate an extended commitment to the > project. > > Tests for these qualities: > >- contacting the right team members to discuss changes > >- actively soliciting feedback for significant changes or new > development > >- multiple independent contributions over a period of several months > >- sponsorship by someone who has worked directly with the candidate > reviewing and committing patches > >- detailed positive feedback from those who have worked directly > with the candidate > >- a record of patches that maintain or improve the quality of the > code without the need for feedback or rework > > Please cast your vote below: > [+1] Adopt the above statements as our official committership criteria. Robbie - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: [QMF] public github repo for QMFv2 api work
Hi Ken, > -Original Message- > From: Ken Giusti [mailto:kgiu...@redhat.com] > Sent: Wednesday, December 09, 2009 9:00 AM > To: dev > Subject: [QMF] public github repo for QMFv2 api work > > > Hi all, > > Just fyi - I've set up a public git repo at github so I can > develop the QMFv2 API code publicly. I've created this > because I am not a committer, but I want this stuff available > to all during development. > > git://github.com/kgiusti/qpid.git > > This repo is based on the apache qpid trunk repo on github. I was in a similar situation when I did the initial Windows port a while back, and I went the git route too. I was advised by more senior Apache people that it's not a good idea because it opens the door to code getting in which hasn't been through the JIRA's "I license this to Apache" check-off. If someone without a CLA drops code into your git repo, then that goes into the svn repo, that's a big problem. FWIW, -Steve - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2253) Cluster node shutsdown with inconsistent error
Cluster node shutsdown with inconsistent error --- Key: QPID-2253 URL: https://issues.apache.org/jira/browse/QPID-2253 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.5 Reporter: Alan Conway Assignee: Alan Conway Fix For: 0.6 Description of problem: When running the "test_failover" test case in the qpid-python-testkit framework where cluster nodes are shutdown and new members are added, a new node just joined encounters an error of the form "confirmed N but only sent N-1" which is only raised on the said member causing it to shut down as inconsistent. Version-Release number of selected component (if applicable): qpid trunk How reproducible: Always Steps to Reproduce: 1. checkout svn 2. build c++ broker and cluster module 3. go to java/testkit/bin and run ./qpid-python-testkit Actual results: cluster2-5: 2009-12-04 14:44:35 notice cluster(192.168.1.103:14491 READY) caught up, active cluster member. cluster2-5: 2009-12-04 14:44:36 error Execution exception: invalid-argument: anonymous.e3a66a8d-330d-47c2-b96d-bb0b1315248b: confirmed < (2+0) but only sent < (1+0) (qpid/SessionState.cpp:151) cluster2-5: 2009-12-04 14:44:36 critical cluster(192.168.1.103:14491 READY/error) local error 599 did not occur on member 192.168.1.103:14453: invalid-argument: anonymous.e3a66a8d-330d-47c2-b96d-bb0b1315248b: confirmed < (2+0) but only sent < (1+0) (qpid/SessionState.cpp:151) cluster2-5: 2009-12-04 14:44:36 error Error delivering frames: local error did not occur on all cluster members : invalid-argument: anonymous.e3a66a8d-330d-47c2-b96d-bb0b1315248b: confirmed < (2+0) but only sent < (1+0) (qpid/SessionState.cpp:151) (qpid/cluster/ErrorCheck.cpp:89) cluster2-5: 2009-12-04 14:44:36 notice cluster(192.168.1.103:14491 LEFT/error) leaving cluster cluster2-helaya:13958 cluster2-5: 2009-12-04 14:44:36 notice Shut down Expected results: There should not be any inconsistent errors. -- 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: [VOTE] Committership Criteria
+1 Adopt the above statements as our official committership criteria. Jonathan - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [VOTE] Committership Criteria
+1 Adopt the above statements as our official committership criteria. Jonathan - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [VOTE] Committership Criteria
On 12/08/2009 02:34 PM, Rafael Schloming wrote: As there have been no comments or questions on the discussion thread, I'm going to move this to a vote: Qualities we look for: - A candidate must demonstrate an understanding of how our project is structured and how we work. - A candidate must communicate openly about work planned/in-progress. - A candidate must demonstrate expertise in a significant area of the existing code base. - A candidate must demonstrate an extended commitment to the project. Tests for these qualities: - contacting the right team members to discuss changes - actively soliciting feedback for significant changes or new development - multiple independent contributions over a period of several months - sponsorship by someone who has worked directly with the candidate reviewing and committing patches - detailed positive feedback from those who have worked directly with the candidate - a record of patches that maintain or improve the quality of the code without the need for feedback or rework Please cast your vote below: [+1] Adopt the above statements as our official committership criteria. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: First Qpid 0.6 Beta Release available for download and testing
On 12/07/2009 11:04 AM, Andrew Stitcher wrote: On Mon, 2009-12-07 at 10:28 -0500, Alan Conway wrote: On 12/04/2009 12:20 PM, Andrew Stitcher wrote: On Fri, 2009-12-04 at 11:07 -0500, Alan Conway wrote: ...On 12/02/2009 07:53 PM, Andrew Stitcher wrote: Cmake build is mostly fine - however the clustering module doesn't build due to a complication of recent versions of boost. The cluster& cluster test build& pass for me on f11 with boost-1.37.0-7.fc11.x86_64, which is the yum latest. Is there a machine I can log into where you see the problem? In response - I don't understand how you can be building this! The StoreStatus.o has references to symbols that are only in libboost_system but it's not directly linked. However having said this I also can't understand why the autotools build does work by the same token - it's a bit of a mystery! ldd shows that in my build cluster.so is indeed linked with boost_system-mt. [acon...@rolf cmake]$ ldd src/cluster.so | grep boost libboost_filesystem-mt.so.4 => /usr/lib64/libboost_filesystem-mt.so.4 (0x7f1d97f67000) libboost_program_options-mt.so.4 => /usr/lib64/libboost_program_options-mt.so.4 (0x7f1d978ac000) libboost_system-mt.so.4 => /usr/lib64/libboost_system-mt.so.4 (0x7f1d95f44000) Also note that libcommon uses boost::filesystem and links without problems, although perhaps StoreStatus is using different symbols. What missing symbols are you seeing? Ok, I haven't explained in enough detail: libqpidcommon isn't a problem because by default shared objects are allowed to have unresolved symbols at link time on the Unix systems I know - if they weren't resolved at the run time load you'd get an error - generally sigkill to the process. ldd doesn't tell you what you need to know here as it gives the transitive linkage - ie in this case libboost_system is loaded because libboost_filesystem requires it. To get the actual (non transitive) requires of an object you need to use objdump -p. When we build plugin modules for qpid we tell the linker to give an error if it finds unresolved symbols when linking against the non transitive requirements (--no-undefined to the linker -Wl,--no-undefined to the compiler). It's possible that libtool adds another option to make it check the symbols transitively, which would explain why the autotools build works, but I can't see why your cmake build could be different from mine. My cmake build does not have those flags in the link line for cluster.so: /usr/bin/ccache /usr/bin/distcc g++ -fPIC -g -O -shared -Wl,-soname,cluster.so -o cluster.so CMakeFiles/cluster.dir/qpid/cluster/Quorum_cman.o CMakeFiles/cluster.dir/qpid/cluster/Cluster.o CMakeFiles/cluster.dir/qpid/cluster/Decoder.o CMakeFiles/cluster.dir/qpid/cluster/ClusterMap.o CMakeFiles/cluster.dir/qpid/cluster/ClusterPlugin.o CMakeFiles/cluster.dir/qpid/cluster/Connection.o CMakeFiles/cluster.dir/qpid/cluster/ConnectionCodec.o CMakeFiles/cluster.dir/qpid/cluster/Cpg.o CMakeFiles/cluster.dir/qpid/cluster/UpdateClient.o CMakeFiles/cluster.dir/qpid/cluster/RetractClient.o CMakeFiles/cluster.dir/qpid/cluster/ErrorCheck.o CMakeFiles/cluster.dir/qpid/cluster/Event.o CMakeFiles/cluster.dir/qpid/cluster/EventFrame.o CMakeFiles/cluster.dir/qpid/cluster/ExpiryPolicy.o CMakeFiles/cluster.dir/qpid/cluster/FailoverExchange.o CMakeFiles/cluster.dir/qpid/cluster/Multicaster.o CMakeFiles/cluster.dir/qpid/cluster/OutputInterceptor.o CMakeFiles/cluster.dir/qpid/cluster/PollerDispatch.o CMakeFiles/cluster.dir/qpid/cluster/InitialStatusMap.o CMakeFiles/cluster.dir/qpid/cluster/MemberSet.o CMakeFiles/cluster.dir/qpid/cluster/StoreStatus.o -lcpg -lcman libqpidbroker.so.0.6 libqpidclient.so.0.6 -lboost_filesystem-mt libqpidcommon.so.0.6 -lboost_program_options-mt -lboost_filesystem-mt -luuid -ldl -lrt -lsasl2 -Wl,-rpath,/home/aconway/qpid/qpid/cmake/src I don't know why those flags aren't present, maybe something wrong with the CMAKE_COMPILER_IS_GNUCXX that's causing it to fail on my box? How can I debug what cmake is doing here? The symbols that are unresolved in all of the shared objects that use boost_filesystem due to inline expansions of things from it are: U boost::system::get_system_category() U boost::system::get_generic_category() Yep, they're undefined for me as well but not causing a compile error due to the missing flags. I'm still not clear on what the solution is here: - drop the --no-undefined-flags - explicitly link with boost system if present We could drop the --no-undefined flag for cluster.so only as a workaround if linking with boost system is tricky. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [VOTE] Committership Criteria
On 12/08/2009 07:34 PM, Rafael Schloming wrote: As there have been no comments or questions on the discussion thread, I'm going to move this to a vote: Sorry for jumping in late here, I was away on holiday when the mail was first sent. Qualities we look for: - A candidate must demonstrate an understanding of how our project is structured and how we work. Could we make this a bit more concrete/specific? For me the key to how we work is a collaborative, consensus based approach to development. What is meant by project structure here? A knowledge of the different components and how they are intended to work as a whole? Or an appreciation of the individuals that work on particular areas (i.e. the team structure)? Or something else? - A candidate must communicate openly about work planned/in-progress. - A candidate must demonstrate expertise in a significant area of the existing code base. - A candidate must demonstrate an extended commitment to the project. Tests for these qualities: - contacting the right team members to discuss changes - actively soliciting feedback for significant changes or new development The above is I think a particularly important point. For new features or components it is vital that there is a clear attempt to build consensus as to the approach taken. Its also important that other members of the community be actively encouraged to try it out and that doing this is made fairly easy. It's often harder to demonstrate collaboration and consensus based development on a new component than it is for fixes and enhancements to existing code (that hopefully already has users and maintainers who will point out issues or ask questions). However it is especially relevant in those situations (to prevent accumulating code that does not have users or maintainers). - multiple independent contributions over a period of several months - sponsorship by someone who has worked directly with the candidate reviewing and committing patches - detailed positive feedback from those who have worked directly with the candidate > - a record of patches that maintain or improve the quality of the code without the need for feedback or rework Please cast your vote below: [ ] Adopt the above statements as our official committership criteria. --Rafael - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[QMF] public github repo for QMFv2 api work
Hi all, Just fyi - I've set up a public git repo at github so I can develop the QMFv2 API code publicly. I've created this because I am not a committer, but I want this stuff available to all during development. git://github.com/kgiusti/qpid.git This repo is based on the apache qpid trunk repo on github. thanks, -K - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Project Etiquette
FWIW, the stuff I wrote was all intended for the benefit of new guys especially, even though I think it is equally good for us to have it written down for ourselves. I'm happy to add to it with some guidelines specifically for new contributors, I'm just less sure of what those are since it's been a while since I was a new contributor. If anyone has specific suggestions, please post and I'm happy to try to incorporate them somehow. As I mentioned, this wasn't intended to be a complete and definitive document, just a start that can evolve. --Rafael Sam Joyce wrote: Hi Folks, Personally I think Carl's idea is a good one, as I am new :) I was involved with QPID and AMQP a few years ago and have only just come back to the fold. I think having a "getting involved - etiquette" section is a good idea. As has already been mentioned, there is a lot of latent awareness about how to go about things, but as a new member of the community it would certainly be of benefit to me to be able to read about it! cheers, Sam. Carl Trieloff wrote: Robert Godfrey wrote: 2009/12/8 Rafael Schloming A number of recent threads have made it clear that we have a fair amount of unspoken etiquette about how we do things around here, and the fact that it is unspoken can be confusing to newcomers and old-timers alike. Looking at a few other apache project web sites, they often seem to have a page or two devoted to documenting their project etiquette. I think this would be a good thing for us to have as well, and I've taken the liberty of trying to seed this effort with some content. I think there are some obvious places where it would make sense to formalize some of this etiquette into some lightweight process, e.g. having maintainers files in svn, having a sandbox for new code contributions, etc, however this text is *not* intended to be a proposal for that sort of thing, merely an attempt to put into words what I believe most of us consider to be the status quo wrt the unspoken etiquette of the project. Of course the problem with unspoken etiquette is that we might not all have the same concept of what it actually is, so please let me know if you disagree with something I've written or you think something important is missing. --Rafael All this sounds very sensible to me; and there's nothing I can immediately think of that I would like to add. Having this on a "Getting Involved" section of the website, along, perhaps, with a list of the "Big Ideas" people are currently working on would seem to make a lot of sense... -- Rob Should we also add a getting involved Etiquette section, i.e. if you are new, how should I work with the team... Carl. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Project Etiquette
Hi Folks, Personally I think Carl's idea is a good one, as I am new :) I was involved with QPID and AMQP a few years ago and have only just come back to the fold. I think having a "getting involved - etiquette" section is a good idea. As has already been mentioned, there is a lot of latent awareness about how to go about things, but as a new member of the community it would certainly be of benefit to me to be able to read about it! cheers, Sam. Carl Trieloff wrote: Robert Godfrey wrote: 2009/12/8 Rafael Schloming A number of recent threads have made it clear that we have a fair amount of unspoken etiquette about how we do things around here, and the fact that it is unspoken can be confusing to newcomers and old-timers alike. Looking at a few other apache project web sites, they often seem to have a page or two devoted to documenting their project etiquette. I think this would be a good thing for us to have as well, and I've taken the liberty of trying to seed this effort with some content. I think there are some obvious places where it would make sense to formalize some of this etiquette into some lightweight process, e.g. having maintainers files in svn, having a sandbox for new code contributions, etc, however this text is *not* intended to be a proposal for that sort of thing, merely an attempt to put into words what I believe most of us consider to be the status quo wrt the unspoken etiquette of the project. Of course the problem with unspoken etiquette is that we might not all have the same concept of what it actually is, so please let me know if you disagree with something I've written or you think something important is missing. --Rafael All this sounds very sensible to me; and there's nothing I can immediately think of that I would like to add. Having this on a "Getting Involved" section of the website, along, perhaps, with a list of the "Big Ideas" people are currently working on would seem to make a lot of sense... -- Rob Should we also add a getting involved Etiquette section, i.e. if you are new, how should I work with the team... Carl. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [VOTE] Committership Criteria
+1 Adopt the below statements as our official committership criteria. regards, Sam. Rafael Schloming wrote: As there have been no comments or questions on the discussion thread, I'm going to move this to a vote: Qualities we look for: - A candidate must demonstrate an understanding of how our project is structured and how we work. - A candidate must communicate openly about work planned/in-progress. - A candidate must demonstrate expertise in a significant area of the existing code base. - A candidate must demonstrate an extended commitment to the project. Tests for these qualities: - contacting the right team members to discuss changes - actively soliciting feedback for significant changes or new development - multiple independent contributions over a period of several months - sponsorship by someone who has worked directly with the candidate reviewing and committing patches - detailed positive feedback from those who have worked directly with the candidate - a record of patches that maintain or improve the quality of the code without the need for feedback or rework Please cast your vote below: [ ] Adopt the above statements as our official committership criteria. --Rafael - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [VOTE] Committership Criteria
2009/12/8 Rafael Schloming : > As there have been no comments or questions on the discussion thread, I'm > going to move this to a vote: > > Qualities we look for: > > - A candidate must demonstrate an understanding of how our project >is structured and how we work. > > - A candidate must communicate openly about work planned/in-progress. > > - A candidate must demonstrate expertise in a significant area of >the existing code base. > > - A candidate must demonstrate an extended commitment to the >project. > > Tests for these qualities: > > - contacting the right team members to discuss changes > > - actively soliciting feedback for significant changes or new >development > > - multiple independent contributions over a period of several months > > - sponsorship by someone who has worked directly with the candidate >reviewing and committing patches > > - detailed positive feedback from those who have worked directly >with the candidate > > - a record of patches that maintain or improve the quality of the >code without the need for feedback or rework > > Please cast your vote below: > [ +1 ] Adopt the above statements as our official committership criteria. > > --Rafael > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > > -- Martin Ritchie - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
