[jira] [Commented] (QPID-3333) Make Python SWIG bindings a drop-in replacement for pure Python qpid.messaging package
[
https://issues.apache.org/jira/browse/QPID-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13060422#comment-13060422
]
Gordon Sim commented on QPID-:
--
The only changes other than the import were around the connection options which
I changed to explicitly use setOption(). Looking at the swig input file and the
changes you made already it seemed like that would be easy to resolve as well
(I just didn't have time right then). One other thing that would be nice would
be getting the string representation of a message to work as in qpid.messaging
(not as important, but nice to have and based again on your existing changes
looked straightforward to a SWIG novice!).
On the imports I just changed:
{noformat}
from qpid.messaging import *
---
from cqpid import *
from qpid.datatypes import uuid4
{noformat}
Make Python SWIG bindings a drop-in replacement for pure Python
qpid.messaging package
--
Key: QPID-
URL: https://issues.apache.org/jira/browse/QPID-
Project: Qpid
Issue Type: Improvement
Components: C++ Client
Affects Versions: 0.11, Future
Reporter: Anthony Foglia
Attachments: 0001-Wrap-NoMessageAvailable-as-Empty-exception.patch,
0002-Change-Connection-interface-to-match-pure-python.patch,
0003-Change-Session-interface-to-match-pure-python.patch,
0004-Change-Receiver-interface-to-match-pure-python.patch,
0005-Change-Sender-interface-to-match-pure-python.patch,
0006-Change-Message-interface-to-match-pure-python.patch
These patches are make the compile Python SWIG bindings to the C++ client
much closer to a drop-in replacement for the Python qpid.messaging package.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Review Request: Keeps track of Qpid runnable threads and other threads, ensuring that rundown doesn't deadlock.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/987/#review965 --- Ship it! Cliff, Thanks for your effort on this. Without this patch test cases would deadlock under NUnit probably the same as under Excel. With the patch the test cases exit and NUnit is happy. -Chuck - Chug On 2011-07-05 17:54:17, Cliff Jansen wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/987/ --- (Updated 2011-07-05 17:54:17) Review request for qpid. Summary --- This is the same logic as the preceding version with naming fixes and refinements to DLL cleanup. Cleanup now uses Windows DllMain function to allows cleanup after C++ runtime static destructors. This addresses bug qpid-3256. https://issues.apache.org/jira/browse/qpid-3256 Diffs - /trunk/qpid/cpp/src/qpid/sys/windows/Thread.cpp 1143151 Diff: https://reviews.apache.org/r/987/diff Testing --- Qpid cmake run_tests Thanks, Cliff
[jira] [Created] (QPID-3337) eliminate guest/guest default username/password and use an explicit sasl mechanism list
eliminate guest/guest default username/password and use an explicit sasl mechanism list --- Key: QPID-3337 URL: https://issues.apache.org/jira/browse/QPID-3337 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Assignee: michael j. goulish Fix For: 0.14 Currently, we default to using the system-default sasl mechanisms list. That list will include GSSAPI if the package is installed on the user's system. But merely installing the GSSAPI package does not prepare qpidd to use GSSAPI. The user must perform specific config steps to make it work. And, since GSSAPI will be selected before other mechanisms, this means that many users will see qpidd fail as soon as they try --auth=yes . It also seems dangerous to allow PLAIN, since users who install qpidd will then have an insecure system by default. By accepting the system-default list we are allowing too many user-surprises. The solution is to explicitly control the mech list, probably only allowing a single mechanism such as DIGEST-MD5, and give the user sufficient instruction on how to set up other mechanisms when they are desired. NOTE -- I am also allowing ANONYMOUS, because some python tools do not yet know how to send credentials, and this will allow them to continue working. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Resolved] (QPID-3337) eliminate guest/guest default username/password and use an explicit sasl mechanism list
[ https://issues.apache.org/jira/browse/QPID-3337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish resolved QPID-3337. -- Resolution: Fixed checkin 1143536 . eliminate guest/guest default username/password and use an explicit sasl mechanism list --- Key: QPID-3337 URL: https://issues.apache.org/jira/browse/QPID-3337 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: michael j. goulish Assignee: michael j. goulish Fix For: 0.14 Currently, we default to using the system-default sasl mechanisms list. That list will include GSSAPI if the package is installed on the user's system. But merely installing the GSSAPI package does not prepare qpidd to use GSSAPI. The user must perform specific config steps to make it work. And, since GSSAPI will be selected before other mechanisms, this means that many users will see qpidd fail as soon as they try --auth=yes . It also seems dangerous to allow PLAIN, since users who install qpidd will then have an insecure system by default. By accepting the system-default list we are allowing too many user-surprises. The solution is to explicitly control the mech list, probably only allowing a single mechanism such as DIGEST-MD5, and give the user sufficient instruction on how to set up other mechanisms when they are desired. NOTE -- I am also allowing ANONYMOUS, because some python tools do not yet know how to send credentials, and this will allow them to continue working. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3256) Application which uses Qpid (in my case Excel) hangs on shutdown
[
https://issues.apache.org/jira/browse/QPID-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13060898#comment-13060898
]
jirapos...@reviews.apache.org commented on QPID-3256:
-
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/987/#review981
---
Ship it!
Looks good to me, Cliff - thanks!
- Steve
On 2011-07-05 17:54:17, Cliff Jansen wrote:
bq.
bq. ---
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/987/
bq. ---
bq.
bq. (Updated 2011-07-05 17:54:17)
bq.
bq.
bq. Review request for qpid.
bq.
bq.
bq. Summary
bq. ---
bq.
bq. This is the same logic as the preceding version with naming fixes and
refinements to DLL cleanup.
bq.
bq. Cleanup now uses Windows DllMain function to allows cleanup after C++
runtime static destructors.
bq.
bq.
bq. This addresses bug qpid-3256.
bq. https://issues.apache.org/jira/browse/qpid-3256
bq.
bq.
bq. Diffs
bq. -
bq.
bq./trunk/qpid/cpp/src/qpid/sys/windows/Thread.cpp 1143151
bq.
bq. Diff: https://reviews.apache.org/r/987/diff
bq.
bq.
bq. Testing
bq. ---
bq.
bq. Qpid cmake run_tests
bq.
bq.
bq. Thanks,
bq.
bq. Cliff
bq.
bq.
Application which uses Qpid (in my case Excel) hangs on shutdown
Key: QPID-3256
URL: https://issues.apache.org/jira/browse/QPID-3256
Project: Qpid
Issue Type: Bug
Components: C++ Client
Affects Versions: 0.8, 0.10
Environment: OS: Windows.
Qpid is assembled as DLL.
Reporter: Eugene
Assignee: Cliff Jansen
Fix For: 0.11
Attachments: qpid-3256-3.patch, qpid-3256.patch
Hi All
I encountered with strange behavior on shutdown when using qpid 0-8 and 0-10.
When I use qpid in standalone console-application everything is ok. But when
I use qpid in DLL which is loaded into Excel (as RTD module), Excel hangs on
shutdown.
I found out that in standalone application on shutdown I have next stack:
qpidclientd.dll!qpid::client::`anonymous
namespace'::IOThread::~IOThread() Line 138C++
qpidclientd.dll!`qpid::client::`anonymous
namespace'::theIO'::`2'::`dynamic atexit destructor for 'io''() + 0xd bytes
C++
qpidclientd.dll!_CRT_INIT(void * hDllHandle=0x6008, unsigned long
dwReason=0, void * lpreserved=0x0001) Line 449 C
qpidclientd.dll!__DllMainCRTStartup(void * hDllHandle=0x6008,
unsigned long dwReason=0, void * lpreserved=0x0001) Line 560 + 0x11
bytesC
qpidclientd.dll!_DllMainCRTStartup(void * hDllHandle=0x6008,
unsigned long dwReason=0, void * lpreserved=0x0001) Line 510 + 0x11
bytes C
ntdll.dll!77b79960()
[Frames below may be incorrect and/or missing, no symbols loaded for
ntdll.dll]
ntdll.dll!77b9a516()
ntdll.dll!77b9a3b8()
kernel32.dll!77657363()
msvcr90d.dll!__crtExitProcess(int status=0) Line 732 C
msvcr90d.dll!doexit(int code=0, int quick=0, int retcaller=0) Line 644
+ 0x9 bytes C
msvcr90d.dll!exit(int code=0) Line 412 + 0xd bytes C
Test.exe!__tmainCRTStartup() Line 599 C
Test.exe!mainCRTStartup() Line 403 C
kernel32.dll!77653677()
ntdll.dll!77b79f02()
ntdll.dll!77b79ed5()
And in this state all threads of application have been already terminated.
The only thread is:
121720 Main Thread Main Thread
qpid::client::`anonymous namespace'::IOThread::~IOThreadNormal 0
so code from file ConnectionImpl.cpp works well:
~IOThread() {
std::vectorThread threads;
{
ScopedLockMutex l(threadLock);
if (poller_)
poller_-shutdown();
t.swap(threads);
}
for (std::vectorThread::iterator i = threads.begin(); i !=
threads.end(); ++i) {
i-join();
}
}
BUT in Excel I get stack:
qpidclientd.dll!qpid::client::`anonymous namespace'::IOThread::~IOThread()
Line 130 C++
qpidclientd.dll!`qpid::client::`anonymous
namespace'::theIO'::`2'::`dynamic atexit destructor for 'io''() + 0xd bytes
C++
qpidclientd.dll!_CRT_INIT(void * hDllHandle=0x0770, unsigned long
dwReason=0, void * lpreserved=0x) Line 449 C
qpidclientd.dll!__DllMainCRTStartup(void * hDllHandle=0x0770,
unsigned long dwReason=0, void * lpreserved=0x) Line 560 + 0x11
Review Request: Concurrently executing connections are allowed to use the same client ID
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/1027/ --- Review request for qpid, Gordon Sim and Robbie Gemmell. Summary --- In order to verify the uniqueness of the client ID, a dummy session is created using client ID as it's name. This prevents any other connection from using same client ID as the session creation will fail. However this verification is switched off by default in order to preserve backwards compatibility. You need to use -Dqpid.verify_client_id=true switch verification on. In summary the following changes were made in order to support the above, 1. A verifyClientID method was added to the connection delegates, 2. AMQSession_0_10.java was modified to allow a name to be specified for the underlying AMQP session. 3. A method was added to o.a.q.transport.Session.java to wait until the session state was changed from NEW to OPEN (or another state which triggers the error). 4. Setter/Getter in Session.java to store/retrieve the SessionDetachCode and ConnectionDelegate to set the detach code. 5. SessionDelegate to notify Session object when attached/dettached/closed is invoked. This addresses bug QPID-3269. https://issues.apache.org/jira/browse/QPID-3269 Diffs - http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQConnection.java 1143628 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQConnectionDelegate.java 1143628 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQConnectionDelegate_0_10.java 1143628 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQConnectionDelegate_8_0.java 1143628 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession_0_10.java 1143628 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/XASessionImpl.java 1143628 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/configuration/ClientProperties.java 1143628 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/ConnectionDelegate.java 1143628 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/Session.java 1143628 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/SessionDelegate.java 1143628 Diff: https://reviews.apache.org/r/1027/diff Testing --- A patch containing a test will be attached to the JIRA shortly. Thanks, rajith
[jira] [Resolved] (QPID-3214) Deadlock between the failover mutex (in AMQConnection.java) and the current_exception_lock (in AMQSession.java)
[ https://issues.apache.org/jira/browse/QPID-3214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajith Attapattu resolved QPID-3214. Resolution: Fixed Fixed. Test cases that were previously deadlocking due to this issue have been working properly since the fix was committed. Deadlock between the failover mutex (in AMQConnection.java) and the current_exception_lock (in AMQSession.java) --- Key: QPID-3214 URL: https://issues.apache.org/jira/browse/QPID-3214 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.10 Reporter: Rajith Attapattu Assignee: Rajith Attapattu Priority: Critical Fix For: 0.11 Attachments: QPID-3214.patch As per the following thread dump you can clearly see the deadlock between the failover mutex in AMQConnection.java and the current_exception_lock in AMQSession.java This is a regression and was introduced in rev 985262 Found one Java-level deadlock: = IoReceiver - localhost/127.0.0.1:15672: waiting to lock monitor 0x002ac2ea3b70 (object 0x002ab70156b0, a java.lang.Object), which is held by main main: waiting to lock monitor 0x002ac28db1b8 (object 0x002ab7048d70, a java.lang.Object), which is held by IoReceiver - localhost/127.0.0.1:15672 Java stack information for the threads listed above: === IoReceiver - localhost/127.0.0.1:15672: at org.apache.qpid.client.AMQConnection.exceptionReceived(AMQConnection.java:1297) - waiting to lock0x002ab70156b0 (a java.lang.Object) at org.apache.qpid.client.AMQSession_0_10.setCurrentException(AMQSession_0_10.java:1033) - locked0x002ab7048d70 (a java.lang.Object) at org.apache.qpid.client.AMQSession_0_10.exception(AMQSession_0_10.java:913) at org.apache.qpid.transport.SessionDelegate.executionException(SessionDelegate.java:156) at org.apache.qpid.transport.SessionDelegate.executionException(SessionDelegate.java:32) at org.apache.qpid.transport.ExecutionException.dispatch(ExecutionException.java:112) at org.apache.qpid.transport.SessionDelegate.command(SessionDelegate.java:50) at org.apache.qpid.transport.SessionDelegate.command(SessionDelegate.java:32) at org.apache.qpid.transport.Method.delegate(Method.java:159) at org.apache.qpid.transport.Session.received(Session.java:528) at org.apache.qpid.transport.Connection.dispatch(Connection.java:404) at org.apache.qpid.transport.ConnectionDelegate.handle(ConnectionDelegate.java:64) at org.apache.qpid.transport.ConnectionDelegate.handle(ConnectionDelegate.java:40) at org.apache.qpid.transport.MethodDelegate.executionException(MethodDelegate.java:110) at org.apache.qpid.transport.ExecutionException.dispatch(ExecutionException.java:112) at org.apache.qpid.transport.ConnectionDelegate.command(ConnectionDelegate.java:54) at org.apache.qpid.transport.ConnectionDelegate.command(ConnectionDelegate.java:40) at org.apache.qpid.transport.Method.delegate(Method.java:159) at org.apache.qpid.transport.Connection.received(Connection.java:369) at org.apache.qpid.transport.Connection.received(Connection.java:59) at org.apache.qpid.transport.network.Assembler.emit(Assembler.java:95) at org.apache.qpid.transport.network.Assembler.assemble(Assembler.java:196) at org.apache.qpid.transport.network.Assembler.frame(Assembler.java:129) at org.apache.qpid.transport.network.Frame.delegate(Frame.java:133) at org.apache.qpid.transport.network.Assembler.received(Assembler.java:100) at org.apache.qpid.transport.network.Assembler.received(Assembler.java:42) at org.apache.qpid.transport.network.InputHandler.next(InputHandler.java:187) at org.apache.qpid.transport.network.InputHandler.received(InputHandler.java:103) at org.apache.qpid.transport.network.InputHandler.received(InputHandler.java:42) at org.apache.qpid.transport.network.io.IoReceiver.run(IoReceiver.java:128) at java.lang.Thread.run(Thread.java:619) main: at org.apache.qpid.client.AMQSession_0_10.setCurrentException(AMQSession_0_10.java:1025) - waiting to lock0x002ab7048d70 (a java.lang.Object) at org.apache.qpid.client.BasicMessageConsumer_0_10.sendCancel(BasicMessageConsumer_0_10.java:193) at org.apache.qpid.client.BasicMessageConsumer.close(BasicMessageConsumer.java:573) - locked0x002ab70156b0 (a java.lang.Object) at org.apache.qpid.client.BasicMessageConsumer.close(BasicMessageConsumer.java:535)
