[jira] [Commented] (QPID-3310) Principal/Subject refactoring
[ https://issues.apache.org/jira/browse/QPID-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058253#comment-13058253 ] Alex Rudyy commented on QPID-3310: -- Keith, Thanks for changes. Patch is fine for me. Principal/Subject refactoring - Key: QPID-3310 URL: https://issues.apache.org/jira/browse/QPID-3310 Project: Qpid Issue Type: Task Components: Java Broker Affects Versions: 0.10 Reporter: Keith Wall Assignee: Keith Wall Fix For: Future Attachments: 0001-QPID-3310-Principal-Subject-refactoring.patch This task is to refactor the broker to pass through a Subject from the authentication layer downwards, rather than a Principal. The motivation for this change is to allow the security modules to make decisions based on all principals (including Group principals) rather than merely the UsernamePrincipal. This task will support QPID-3283. -- 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: Qpid specific properties for retrieving information
On 06/30/2011 08:15 PM, Rajith Attapattu wrote: On Thu, Jun 30, 2011 at 12:59 PM, Gordon Simg...@redhat.com wrote: On 06/30/2011 05:43 PM, Rajith Attapattu wrote: Sharing and documenting these props will help ensure that all clients support it to provide a uniform experience to our end users. Agreed. I have collection what I know so far here [1]. If anybody knows about other props feel free to add it there or simple respond to this email. I also suggest we follow a naming convention. Based on what we have, I see the following being used. 1. For retrieving AMQP specific information (Ex the routing-key.) x-amqp-amqp-version.property-name - Ex x-amqp-0-10.routing-key, x-amqp-0-10.app-id The c++ client also has x-amqp-0-10.content-encoding, I think more for completeness than any specific need to use it. As requested on the user list, this would be a useful addition for JMS clients. Note that is content-encoding, not content-type. Having content-type exposed in JMS is indeed very valuable. content-encoding as a separate field in 0-10 is not used as far as I'm aware. The content-type is (however in the messaging API it is exposed directly, these special properties are only used to access 0-10 specific fields not deemed to have generic counterparts). - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Assigned] (QPID-3330) Address strings unable to have empty strings as option values
[
https://issues.apache.org/jira/browse/QPID-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim reassigned QPID-3330:
Assignee: Gordon Sim
Address strings unable to have empty strings as option values
-
Key: QPID-3330
URL: https://issues.apache.org/jira/browse/QPID-3330
Project: Qpid
Issue Type: Bug
Components: C++ Client
Affects Versions: 0.10, 0.11
Reporter: Anthony Foglia
Assignee: Gordon Sim
Attachments: 0001-Correctly-parse-empty-strings.patch
The Address object can not be constructed from option maps that have empty
strings as values, because of parser errors. (e.g. Address(inbound; { key:
'' }).)
The issue is in AddressParser::readString. Going into it, current points to
the delimiter. The readChar call moves current up to one past the delimiter.
Then definition of start as current++ moves it one further, which is past
the closing delimiter of an empty string.
--
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: Proposed QIP: Support for Message Grouping in the broker.
Folks, Here's a second draft of the proposal. I've tried to incorporate the feedback provided during the last week. And I have tried to limit the proposed feature set a bit more. Opinions welcome, thanks - -K # Message Groups ## Status Draft ## Summary This document describes a new feature that would allow an application to classify a set of related messages as belonging to a group. This document also describes two policies that the broker could apply when delivering a message group to one or more consumers. ## Problem It would be useful to give an application the ability to classify a set of messages as belonging to a single unit of work. Furthermore, if the broker can identify messages belonging to the same unit of work, it can enforce policies that control how that unit of work can be consumed. For example, it may be desirable to guarantee that a particular set of messages are consumed by the same client, even in the case where there are multiple clients consuming from the same queue. In a different scenario, it may be permissible for different clients to consume messages from the same group, as long as it can be guaranteed that the individual messages are not processed in parallel. In other words, the broker would ensure that messages are processed by consumers in the same order in which they were enqueued. For example, assume we have a shopping application that manages items in a virtual shopping cart. A user may add an item to their shopping cart, then change their mind and remove it. If the application sends an add message to the broker, immediately followed by a remove message, they will be queued in the proper order - add, then remove. However, if there are multiple consumers, it is possible that once a consumer acquires the add message, a different consumer may acquire the remove message. This allows both messages to be processed in parallel, which could result in the remove operation being performed before the add operation. ## Solution This QIP proposes the following: 1) provide the ability for a message producer to designate a set of messages as belonging to the same group. 2) allow the broker to identify messages that belong to the same group. 3) define policies for the broker that control the delivery of messages belonging to the same group. For #1: The sending application would define a message header that would contain the message's group identifier. The group identifier stored in that header field would be a string value determined by the application. Messages from the same group would have the same group identifier value. For #2: The key for the header that contains the group identifier would be provided to the broker via configuration. From the broker's perspective, the number of different group id values would be unlimited. And the value of group identifiers would not be provided ahead of time by configuration: the broker must learn them at runtime. For #3: This QIP defines two message group policies. Additional policies may be defined in the future. Policy 1: Exclusive Consumer With this policy, the broker would guarantee that all messages in a group would be delivered to the same client. This policy would be configured on a per-queue basis. When the first message of a new message group becomes available for delivery, the broker will associate that group with the next available consumer. The broker would then guarantee that all messages from that group are delivered to that consumer only. The broker will maintain the group/client association for the lifetime of the client. Should the client die or cancel its subscription, any unacknowledged messages in the group will be assigned to a different client (preserving message order). Group/client associations are not maintained across broker restart. These associations must be replicated in a clustered broker. Policy #2: Sequenced Consumers With this policy, the broker would guarantee that the order in which messages in a group are processed by consumers is the same order in which the messages where enqueued. This guarantee would be upheld even if the messages of the group are processed by different consumers. No two messages from the same group would be processed in parallel by different consumers. Specifically, for any given group, the broker allows only the first N messages in the group to be available for delivery to a particular consumer. The value of N would be determined by the selected consumer's configured prefetch capacity. The broker blocks access to the remaining messages in that group by any other consumer. Once the selected consumer has acknowledged that first set of delivered messages, the broker allows the next messages in the group to be available for delivery. The next set of messages may be delivered to a different consumer. This policy would be configured on a per-queue basis. Configuration would include designating the key of the application header that
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/#review947 --- My concern with DllMain is that it precludes building qpid as static libraries (and having this logic still work). - Steve On 2011-07-01 03:08:08, Cliff Jansen wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/987/ --- (Updated 2011-07-01 03:08:08) 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 1141687 Diff: https://reviews.apache.org/r/987/diff Testing --- Qpid cmake run_tests Thanks, Cliff
Re: Review Request: Keep better track of threads avoiding deadlocks at process rundown
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/904/#review948 --- This was continued in a separate review request, https://reviews.apache.org/r/987/ - Steve On 2011-06-15 01:08:18, Steve Huston wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/904/ --- (Updated 2011-06-15 01:08:18) Review request for qpid. Summary --- Keeps track of Qpid runnable threads and other threads, ensuring that rundown doesn't deadlock. This addresses bug QPID-3256. https://issues.apache.org/jira/browse/QPID-3256 Diffs - /trunk/qpid/cpp/src/qpid/sys/windows/Thread.cpp 1132733 Diff: https://reviews.apache.org/r/904/diff Testing --- Qpid regression test suite. Thanks, Steve
[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=13058499#comment-13058499
]
jirapos...@reviews.apache.org commented on QPID-3256:
-
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/987/#review947
---
My concern with DllMain is that it precludes building qpid as static libraries
(and having this logic still work).
- Steve
On 2011-07-01 03:08:08, 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-01 03:08:08)
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 1141687
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.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
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/#review949 --- Admin note... when this review is resolved, please ensure that https://reviews.apache.org/r/904/ is cleaned up accordingly. - Steve On 2011-07-01 03:08:08, Cliff Jansen wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/987/ --- (Updated 2011-07-01 03:08:08) 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 1141687 Diff: https://reviews.apache.org/r/987/diff Testing --- Qpid cmake run_tests Thanks, Cliff
[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=13058502#comment-13058502
]
jirapos...@reviews.apache.org commented on QPID-3256:
-
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/987/#review949
---
Admin note... when this review is resolved, please ensure that
https://reviews.apache.org/r/904/ is cleaned up accordingly.
- Steve
On 2011-07-01 03:08:08, 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-01 03:08:08)
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 1141687
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.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
[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=13058503#comment-13058503
]
jirapos...@reviews.apache.org commented on QPID-3256:
-
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/904/#review948
---
This was continued in a separate review request,
https://reviews.apache.org/r/987/
- Steve
On 2011-06-15 01:08:18, Steve Huston wrote:
bq.
bq. ---
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/904/
bq. ---
bq.
bq. (Updated 2011-06-15 01:08:18)
bq.
bq.
bq. Review request for qpid.
bq.
bq.
bq. Summary
bq. ---
bq.
bq. Keeps track of Qpid runnable threads and other threads, ensuring that
rundown doesn't deadlock.
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 1132733
bq.
bq. Diff: https://reviews.apache.org/r/904/diff
bq.
bq.
bq. Testing
bq. ---
bq.
bq. Qpid regression test suite.
bq.
bq.
bq. Thanks,
bq.
bq. Steve
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.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
bytesC
qpidclientd.dll!_DllMainCRTStartup(void * hDllHandle=0x0770,
[jira] [Resolved] (QPID-3330) Address strings unable to have empty strings as option values
[
https://issues.apache.org/jira/browse/QPID-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim resolved QPID-3330.
--
Resolution: Fixed
Fix Version/s: 0.13
Address strings unable to have empty strings as option values
-
Key: QPID-3330
URL: https://issues.apache.org/jira/browse/QPID-3330
Project: Qpid
Issue Type: Bug
Components: C++ Client
Affects Versions: 0.10, 0.11
Reporter: Anthony Foglia
Assignee: Gordon Sim
Fix For: 0.13
Attachments: 0001-Correctly-parse-empty-strings.patch
The Address object can not be constructed from option maps that have empty
strings as values, because of parser errors. (e.g. Address(inbound; { key:
'' }).)
The issue is in AddressParser::readString. Going into it, current points to
the delimiter. The readChar call moves current up to one past the delimiter.
Then definition of start as current++ moves it one further, which is past
the closing delimiter of an empty string.
--
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: QMF Questions....
On 06/30/2011 12:50 PM, Gordon Sim wrote: On 06/30/2011 05:36 PM, Carl Trieloff wrote: On 06/30/2011 12:21 PM, Gordon Sim wrote: 1) Is it possible for a client to recover the --default-queue-limit for a broker? No, I'm afraid not. This should however be trivial to add and quite useful. add an R param for it to management-schema.xml, and the initialize it in the construction of the queue. I think a more useful change would be to expose the current broker configuration. If you want to modify the schema for the queue then I think the right approach is to explicitly model the actual policy values in use (at present it is just the arguments presented when the queue was created that are exposed). I think it would be better to add the defaults to the queue args on queue construction. that way they will a.) show up in QMF data, b.) it is simpler and we don't have to maintain a separate model, c.) if the queue is persisted and then restored, it will restore with the defaults at the time of creation, and not be affected by config changes, or broker updates Carl. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: QMF Questions....
On 07/01/2011 02:17 PM, Carl Trieloff wrote: On 06/30/2011 12:50 PM, Gordon Sim wrote: On 06/30/2011 05:36 PM, Carl Trieloff wrote: On 06/30/2011 12:21 PM, Gordon Sim wrote: 1) Is it possible for a client to recover the --default-queue-limit for a broker? No, I'm afraid not. This should however be trivial to add and quite useful. add an R param for it to management-schema.xml, and the initialize it in the construction of the queue. I think a more useful change would be to expose the current broker configuration. If you want to modify the schema for the queue then I think the right approach is to explicitly model the actual policy values in use (at present it is just the arguments presented when the queue was created that are exposed). I think it would be better to add the defaults to the queue args on queue construction. that way they will a.) show up in QMF data, b.) it is simpler and we don't have to maintain a separate model, c.) if the queue is persisted and then restored, it will restore with the defaults at the time of creation, and not be affected by config changes, or broker updates That is one way of doing the modelling certainly, and I wouldn't object to it. I think you need to be consistent about it though and have the 'arguments' essentially represent the properties of the queue. We would then want to remove any unrecognised options (detecting those is something I've wanted to do for sometime now anyway). We would want to ensure that the policy recorded was the one used (and not the one specified which is not always the same things) etc. I agree that having a loose set of properties defined in the schema that are then more easily evolvable is nice (of course the schema then is not a sufficient description on it's own, but I don't have an issue with that). - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3335) Remove duplicate and buggy type conversion code from Management Agent.
Remove duplicate and buggy type conversion code from Management Agent. -- Key: QPID-3335 URL: https://issues.apache.org/jira/browse/QPID-3335 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.11 Reporter: Ken Giusti Assignee: Ken Giusti Fix For: 0.12 The broker's management agent exports a FieldTable to Variant Map translation API. This duplicates the translation code from the common library (Codecs.h), and the version in the management agent is stale and buggy. Remove the duplication and have the management agent use the common code. -- 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-3335) Remove duplicate and buggy type conversion code from Management Agent.
[ https://issues.apache.org/jira/browse/QPID-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058560#comment-13058560 ] jirapos...@reviews.apache.org commented on QPID-3335: - --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/988/#review952 --- Ship it! - Gordon On 2011-07-01 13:58:26, Kenneth Giusti wrote: bq. bq. --- bq. This is an automatically generated e-mail. To reply, visit: bq. https://reviews.apache.org/r/988/ bq. --- bq. bq. (Updated 2011-07-01 13:58:26) bq. bq. bq. Review request for Gordon Sim, Kim van der Riet and Ted Ross. bq. bq. bq. Summary bq. --- bq. bq. Removes some old code that duplicates type conversions that are available in the common library. bq. bq. bq. This addresses bug qpid-3335. bq. https://issues.apache.org/jira/browse/qpid-3335 bq. bq. bq. Diffs bq. - bq. bq./trunk/qpid/cpp/src/qpid/management/ManagementAgent.h 1141932 bq./trunk/qpid/cpp/src/qpid/management/ManagementAgent.cpp 1141932 bq. bq. Diff: https://reviews.apache.org/r/988/diff bq. bq. bq. Testing bq. --- bq. bq. unit. bq. bq. bq. Thanks, bq. bq. Kenneth bq. bq. Remove duplicate and buggy type conversion code from Management Agent. -- Key: QPID-3335 URL: https://issues.apache.org/jira/browse/QPID-3335 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.11 Reporter: Ken Giusti Assignee: Ken Giusti Fix For: 0.12 The broker's management agent exports a FieldTable to Variant Map translation API. This duplicates the translation code from the common library (Codecs.h), and the version in the management agent is stale and buggy. Remove the duplication and have the management agent use the common code. -- 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-3335) Remove duplicate and buggy type conversion code from Management Agent.
[ https://issues.apache.org/jira/browse/QPID-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved QPID-3335. -- Resolution: Fixed Remove duplicate and buggy type conversion code from Management Agent. -- Key: QPID-3335 URL: https://issues.apache.org/jira/browse/QPID-3335 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.12 Reporter: Ken Giusti Assignee: Ken Giusti Fix For: 0.13 The broker's management agent exports a FieldTable to Variant Map translation API. This duplicates the translation code from the common library (Codecs.h), and the version in the management agent is stale and buggy. Remove the duplication and have the management agent use the common code. -- 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] [Updated] (QPID-3335) Remove duplicate and buggy type conversion code from Management Agent.
[ https://issues.apache.org/jira/browse/QPID-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated QPID-3335: - Affects Version/s: (was: 0.11) 0.12 Fix Version/s: (was: 0.12) 0.13 Remove duplicate and buggy type conversion code from Management Agent. -- Key: QPID-3335 URL: https://issues.apache.org/jira/browse/QPID-3335 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.12 Reporter: Ken Giusti Assignee: Ken Giusti Fix For: 0.13 The broker's management agent exports a FieldTable to Variant Map translation API. This duplicates the translation code from the common library (Codecs.h), and the version in the management agent is stale and buggy. Remove the duplication and have the management agent use the common code. -- 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.
On 2011-07-01 11:44:51, Steve Huston wrote: My concern with DllMain is that it precludes building qpid as static libraries (and having this logic still work). Good point. I was so focused on the bug as presented I lost complete sight of this valid use case. I suppose I could do away with locks and maps altogether with use of TLS storage. In this case the only leaked resource would be the TLS slot on multiple uses of LoadLibrary/FreeLibrary, which is obviously not relevant in the static build case. So I should be able to use logic to free the slot in DllMain and comment out that code in a static build. Does this seem reasonable? - Cliff --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/987/#review947 --- On 2011-07-01 03:08:08, Cliff Jansen wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/987/ --- (Updated 2011-07-01 03:08:08) 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 1141687 Diff: https://reviews.apache.org/r/987/diff Testing --- Qpid cmake run_tests Thanks, Cliff
[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=13058714#comment-13058714
]
jirapos...@reviews.apache.org commented on QPID-3256:
-
bq. On 2011-07-01 11:44:51, Steve Huston wrote:
bq. My concern with DllMain is that it precludes building qpid as static
libraries (and having this logic still work).
Good point. I was so focused on the bug as presented I lost complete sight of
this valid use case.
I suppose I could do away with locks and maps altogether with use of TLS
storage. In this case the only leaked resource would be the TLS slot on
multiple uses of LoadLibrary/FreeLibrary, which is obviously not relevant in
the static build case. So I should be able to use logic to free the slot in
DllMain and comment out that code in a static build. Does this seem reasonable?
- Cliff
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/987/#review947
---
On 2011-07-01 03:08:08, 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-01 03:08:08)
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 1141687
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.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 !=
Re: Review Request: Keeps track of Qpid runnable threads and other threads, ensuring that rundown doesn't deadlock.
On 2011-07-01 11:44:51, Steve Huston wrote: My concern with DllMain is that it precludes building qpid as static libraries (and having this logic still work). Cliff Jansen wrote: Good point. I was so focused on the bug as presented I lost complete sight of this valid use case. I suppose I could do away with locks and maps altogether with use of TLS storage. In this case the only leaked resource would be the TLS slot on multiple uses of LoadLibrary/FreeLibrary, which is obviously not relevant in the static build case. So I should be able to use logic to free the slot in DllMain and comment out that code in a static build. Does this seem reasonable? Yes it does - thanks! - Steve --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/987/#review947 --- On 2011-07-01 03:08:08, Cliff Jansen wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/987/ --- (Updated 2011-07-01 03:08:08) 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 1141687 Diff: https://reviews.apache.org/r/987/diff Testing --- Qpid cmake run_tests Thanks, Cliff
[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=13058734#comment-13058734
]
jirapos...@reviews.apache.org commented on QPID-3256:
-
bq. On 2011-07-01 11:44:51, Steve Huston wrote:
bq. My concern with DllMain is that it precludes building qpid as static
libraries (and having this logic still work).
bq.
bq. Cliff Jansen wrote:
bq. Good point. I was so focused on the bug as presented I lost complete
sight of this valid use case.
bq.
bq. I suppose I could do away with locks and maps altogether with use of
TLS storage. In this case the only leaked resource would be the TLS slot on
multiple uses of LoadLibrary/FreeLibrary, which is obviously not relevant in
the static build case. So I should be able to use logic to free the slot in
DllMain and comment out that code in a static build. Does this seem reasonable?
Yes it does - thanks!
- Steve
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/987/#review947
---
On 2011-07-01 03:08:08, 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-01 03:08:08)
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 1141687
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.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);
}
