[jira] [Commented] (QPID-2794) Broker shutdown logic needs changing to run inside another process
[ https://issues.apache.org/jira/browse/QPID-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057693#comment-13057693 ] Robbie Gemmell commented on QPID-2794: -- Hi Danushka, The Main class really isnt intended for use in this fashion, which is why you are running into issues such as QPID-3323 and QPID-2794. As part of the work I am currently doing the broker startup is seperated from the Main class entirely, which should give you the functionality you seem to be looking for without resorting to hacking at Main in the ways these patches do. I'll update these JIRAs once that work is available. Robbie Broker shutdown logic needs changing to run inside another process -- Key: QPID-2794 URL: https://issues.apache.org/jira/browse/QPID-2794 Project: Qpid Issue Type: Bug Components: Java Broker Reporter: Danushka Menikkumbura Assignee: Robbie Gemmell Attachments: QPID-2794.patch At the moment the broker shutdown terminates the JVM which is a problem when the broker runs inside another process. -- 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] [Assigned] (QPID-3026) The ApplicationRegistry object should be a singleton
[ https://issues.apache.org/jira/browse/QPID-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall reassigned QPID-3026: Assignee: Keith Wall (was: Andrew Kennedy) The ApplicationRegistry object should be a singleton Key: QPID-3026 URL: https://issues.apache.org/jira/browse/QPID-3026 Project: Qpid Issue Type: Improvement Components: Java Broker Affects Versions: 0.9 Reporter: Andrew Kennedy Assignee: Keith Wall Priority: Minor Fix For: 0.11 The ApplicationRegistry can currently have multiple instances, in order to cater for multiple brokers in the same VM. However, *many* parts of the code simply call ApplcationRegistry.getInstance() to obtain a reference, meaning multiple instances are ignored. The only time this is ever useful is for certain types of tests, therefore the capability to have multiple broker instances should be removed. Any tests that require multiple brokers can start a VM broker and an external, or two external brokers. In general, test-only code should not be made available to the rest of the application. -- 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-3325) Make it possible to access broker shutdown hook from outside
[ https://issues.apache.org/jira/browse/QPID-3325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057706#comment-13057706 ] Keith Wall commented on QPID-3325: -- Hi Danushka I've reviewed your patch. First, I have a question. For what purpose does calling code require access to the ShutdownServiceThread? If it is so the calling code can can *unregister* the shutdown hook, then I think it would be better if ApplicationRegistry itself took on this responsibility. I think ApplicationRegistry should register the shutdown hook on initialisation (initialise()), and remove the shutdown hook when the remove is called (currently remove/removeAll()). I am currently working in ApplicationRegistry (QPID-3026) and could incorporate this improvement too. Please let me know your thoughts. Kind regards Keith Wall. Make it possible to access broker shutdown hook from outside Key: QPID-3325 URL: https://issues.apache.org/jira/browse/QPID-3325 Project: Qpid Issue Type: Improvement Reporter: Danushka Menikkumbura Assignee: Robbie Gemmell Attachments: QPID-3325.patch -- 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-3310) Principal/Subject refactoring
[ https://issues.apache.org/jira/browse/QPID-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-3310: - Attachment: (was: 0001-QPID-3310-Principal-Subject-refactoring.patch) 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 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
[jira] [Updated] (QPID-3310) Principal/Subject refactoring
[ https://issues.apache.org/jira/browse/QPID-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-3310: - Attachment: 0001-QPID-3310-Principal-Subject-refactoring.patch Hi Alex As discussed, I've incorporated your latest comments and recreated the patch. Thanks Keith 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
[jira] [Updated] (QPID-3324) Make it possible to give SSL port as an argument at broker start up
[ https://issues.apache.org/jira/browse/QPID-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-3324: - Status: Ready To Review (was: In Progress) Make it possible to give SSL port as an argument at broker start up --- Key: QPID-3324 URL: https://issues.apache.org/jira/browse/QPID-3324 Project: Qpid Issue Type: Improvement Reporter: Danushka Menikkumbura Assignee: Robbie Gemmell Attachments: QPID-3324.patch -- 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-3324) Make it possible to give SSL port as an argument at broker start up
[ https://issues.apache.org/jira/browse/QPID-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-3324. -- Resolution: Fixed Fix Version/s: 0.11 Patch applied. Make it possible to give SSL port as an argument at broker start up --- Key: QPID-3324 URL: https://issues.apache.org/jira/browse/QPID-3324 Project: Qpid Issue Type: Improvement Reporter: Danushka Menikkumbura Assignee: Robbie Gemmell Fix For: 0.11 Attachments: QPID-3324.patch -- 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: Synchronous I/O in Ruby client...
On 06/29/2011 02:06 PM, Darryl L. Pierce wrote:
In working on the Ruby layer I've hit a serious road block.
For any call that blocks on I/O (Session.synch :block = true) the Ruby
bindings can _not_ wrap that call in a Ruby thread and have it run while
the main application thread continues to run. So, even though we do
this:
def sync(args = {},callback)
block = args[:block] || false
if block
# Spawn a thread to run the sync
Thread.new do
@session_impl.sync true
callback.call if callback
end
else
@sessimpl_impl.sync false
callback.call if callback
end
end
the call to Session.sync will still block the whole application until
the call completes.
Not sure I follow here: if the call is blocking you _want_ the calling thread to
be blocked till the call completes so what is wrong with:
def sync(args = {})
block = args[:block] || false
@session_impl.sync block
Of course that doesn't allow you to have a callback invoked in non-blocking mode
but C++ and python APIs don't currently support this either. When the underlying
swigged API is improved to allow callbacks or futures for sync=false calls then
that can be exposed in ruby.
In Ruby 1.9 we'll have other options to work with this since pthreads
will be available in the code. But, for now, we won't be able to use
_Ruby_ threads to work around this limitation.
So in thinking this over, I see one of two paths to go down:
1. Create a C++ child class of Session (and other classes that have
blocking I/O) and, when a blocking call is made, wrap the call in a
native thread. Then have the native code invoke the lamda funtion, and
make that lamda a requirement for such a call.
I would prefer to see the underlying API improved to provide callbacks or
futures for non-blocking calls.
Then a blocking call could be implemented as a non-blocking call to C++, plus
ruby code to wait for the response without blocking the whole app. Not sure
if/how the waiting and notification will work between pthreads in the C++ layer
and ruby threads however.
2. Inform the developer that blocking calls will stop the application
until Ruby 1.9.
Isn't that already the case with any blocking IO operation? So its something
ruby developers are already living with.
Agreed it is not a good thing but I think it's going to be difficult to solve
this in Ruby until it is better solved in the underlying API and/or ruby gets
pthreads.
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Synchronous I/O in Ruby client...
On 06/29/2011 07:43 PM, Darryl L. Pierce wrote: On Wed, Jun 29, 2011 at 04:58:36PM +0100, Gordon Sim wrote: 1. Create a C++ child class of Session (and other classes that have blocking I/O) and, when a blocking call is made, wrap the call in a native thread. Then have the native code invoke the lamda funtion, and make that lamda a requirement for such a call. I'm not too keen on this, it seems at best a short term fix... I agree. I put that out that as one possible path, but it's too easily a vector for Ruby-specific problems. 2. Inform the developer that blocking calls will stop the application until Ruby 1.9. Thoughts? ...another approach is to ensure that the API being SWIGed supports non-blocking usage effectively. Though that will take more effort it seems a nicer solution long term. I would certainly like to enhance the c++ messaging API in this way. What do you mean by supports non-blocking usage more effectively? What I would like to do, and what is more Ruby-ish, would be to call the non-blocking version but provide a lambda function that can be called. A more Ruby-like way would be to have Ruby _not_ pass :block = true to the underlying implementation and, instead, require the user pass in a lambda function. Then the API could spawn a Ruby thread, do the sync, and then call the lambda function after it completes. So we never _actually_ block the thread while the call runs. But we give the user a means for knowing when the call finishes (which is what I assume is the goal of the synchronous call since it returns no value). That is the right idea, but how do you wait for the underlying non-blocking operation to complete? We need to add callbacks or futures to the C++ non-blocking operations to do this. But a C++ callback may be called in a non-ruby thread, I don't know what facilities ruby has to resolve that. A future just moves the problem - when you call future.wait() you'll block ruby again. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Resolved] (QPID-3329) Configure C++ client connections to replace url-addresses rather than merging new addresses with old
[ https://issues.apache.org/jira/browse/QPID-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved QPID-3329. --- Resolution: Fixed Fix Version/s: 0.11 Reviewed https://reviews.apache.org/r/978/ Comitted to trunk: r1141493 Configure C++ client connections to replace url-addresses rather than merging new addresses with old Key: QPID-3329 URL: https://issues.apache.org/jira/browse/QPID-3329 Project: Qpid Issue Type: Improvement Reporter: Alan Conway Assignee: Alan Conway Fix For: 0.11 Setting the reconnect-urls client option actually merges the new URLs with the old. This patch allows that to be configured: if reconnect-urls-replace is set to true then the old URLs are replaced instead. This us useful in long-running failover tests that generate an unlimited series of different broker addresses. The default is the old merge behaviour as this is safer for a fixed-size cluster: in the event of a partion you don't want the failover list to be replaced by a list containing only the losing brokers, that would leave the client stranded. -- 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: Synchronous I/O in Ruby client...
On Thu, Jun 30, 2011 at 11:38:26AM +0100, Alan Conway wrote:
For any call that blocks on I/O (Session.synch :block = true) the Ruby
bindings can _not_ wrap that call in a Ruby thread and have it run while
the main application thread continues to run. So, even though we do
this:
def sync(args = {},callback)
block = args[:block] || false
if block
# Spawn a thread to run the sync
Thread.new do
@session_impl.sync true
callback.call if callback
end
else
@sessimpl_impl.sync false
callback.call if callback
end
end
the call to Session.sync will still block the whole application until
the call completes.
Not sure I follow here: if the call is blocking you _want_ the
calling thread to be blocked till the call completes so what is
wrong with:
I don't know that we want all threads to block. To my mind the goal is
we want to perform some action after the call finishes, some call which
depends on the blocking I/O completion before it can continue.
def sync(args = {})
block = args[:block] || false
@session_impl.sync block
Of course that doesn't allow you to have a callback invoked in
non-blocking mode but C++ and python APIs don't currently support
this either. When the underlying swigged API is improved to allow
callbacks or futures for sync=false calls then that can be exposed
in ruby.
In Ruby 1.9 we'll have other options to work with this since pthreads
will be available in the code. But, for now, we won't be able to use
_Ruby_ threads to work around this limitation.
So in thinking this over, I see one of two paths to go down:
1. Create a C++ child class of Session (and other classes that have
blocking I/O) and, when a blocking call is made, wrap the call in a
native thread. Then have the native code invoke the lamda funtion, and
make that lamda a requirement for such a call.
I would prefer to see the underlying API improved to provide
callbacks or futures for non-blocking calls.
Then a blocking call could be implemented as a non-blocking call to
C++, plus ruby code to wait for the response without blocking the
whole app. Not sure if/how the waiting and notification will work
between pthreads in the C++ layer and ruby threads however.
I think even with the callback model we'll still need to handle threads
at some layer below the Ruby code.
2. Inform the developer that blocking calls will stop the application
until Ruby 1.9.
Isn't that already the case with any blocking IO operation? So its
something ruby developers are already living with.
Yeah. I was asked to try and solve this problem now, though. So I'm
trying to entertain all options for how we could overcome this blocking
behavior.
The way that seems to be the only path for this would be to put a layer
between the swigged APIs and the Ruby bindings I've written to add some
threading support only for blocking calls. The layer would take a
reference to a Proc object, start a native thread, and then invoke the
Proc object's callback when the thread completes.
Agreed it is not a good thing but I think it's going to be difficult
to solve this in Ruby until it is better solved in the underlying
API and/or ruby gets pthreads.
That'll be the case in Ruby 1.9.
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
pgpUIThFrBcHZ.pgp
Description: PGP signature
Re: Synchronous I/O in Ruby client...
On 06/30/2011 11:55 AM, Alan Conway wrote: On 06/29/2011 07:43 PM, Darryl L. Pierce wrote: On Wed, Jun 29, 2011 at 04:58:36PM +0100, Gordon Sim wrote: ...another approach is to ensure that the API being SWIGed supports non-blocking usage effectively. Though that will take more effort it seems a nicer solution long term. I would certainly like to enhance the c++ messaging API in this way. What do you mean by supports non-blocking usage more effectively? What I would like to do, and what is more Ruby-ish, would be to call the non-blocking version but provide a lambda function that can be called. A more Ruby-like way would be to have Ruby _not_ pass :block = true to the underlying implementation and, instead, require the user pass in a lambda function. Then the API could spawn a Ruby thread, do the sync, and then call the lambda function after it completes. So we never _actually_ block the thread while the call runs. But we give the user a means for knowing when the call finishes (which is what I assume is the goal of the synchronous call since it returns no value). That is the right idea, but how do you wait for the underlying non-blocking operation to complete? We need to add callbacks or futures to the C++ non-blocking operations to do this. But a C++ callback may be called in a non-ruby thread, I don't know what facilities ruby has to resolve that. A future just moves the problem - when you call future.wait() you'll block ruby again. What I would like to do in the c++ API is have a better way to wait for something of interest to happen on a connection (or even better on a set of connections). There would then also need to be a simple and efficient way to determine what has actually happened (e.g. is it an incoming message on a session associated with the connection, the availability of credit enabling further publication on a session, the confirmation of status on a particular transfer in either direction etc). This second part might for example be the addition of a Connection::nextSession() and Session::nextSender() that were analogous to the Session::nextReceiver() call we already have. The 'settlement' of transferred messages in either direction is currently exposed through counters on unsettled sent and acknowledged messages. The first part is really some sort of polling mechanism. It could perhaps be driven off IO events since ultimately that is what will trigger any higher level event of interest. Certainly it involves some sort of EventMachine like interface. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Synchronous I/O in Ruby client...
On 06/30/2011 03:05 PM, Alan Conway wrote: I'd like to see something like: - a thread safe get next event call that returns events for message delivery, async responses and any other triggers coming from the broker - a file descriptor that is readable whenever there are qpid events pending so you can knit this into a poll/epoll/select loop - an ease-of-use layer that provides ready-made thread pool implementations of common dispatch policies e.g. message listeners, thread-per-connection, thread-per-session, thread-per-message etc. Yes, I like that. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: svn commit: r1141543 - /qpid/branches/0.12/
Good idea. I'll use that for the upcoming version number changes. Justin On Thu, 30 Jun 2011, Rajith Attapattu wrote: This is just an idea. Instead of using NO-JIRA we could create a JIRA for 0.12 and then use that for all administrative commits related to 0.12 Ex. creating the branch, creating tags or even use that as a secondary JIRA when porting changes from trunk to release branch. The advantage here is, that there is a single place which gives you a list of all the (administrative) commits related to a particular release. It certainly provides a nice audit trail and gives the release manager an easy way to keep track of all changes going into the release branch. Regards, Rajith On Thu, Jun 30, 2011 at 10:02 AM, jr...@apache.org wrote: Author: jross Date: Thu Jun 30 14:02:01 2011 New Revision: 1141543 URL: http://svn.apache.org/viewvc?rev=1141543view=rev Log: NO-JIRA: Branch for the 0.12 release Added: qpid/branches/0.12/ (props changed) - copied from r1141493, qpid/trunk/ Propchange: qpid/branches/0.12/ -- --- svn:mergeinfo (added) +++ svn:mergeinfo Thu Jun 30 14:02:01 2011 @@ -0,0 +1,3 @@ +/qpid/branches/0.5.x-dev:892761,894875 +/qpid/branches/0.6-release-windows-installer:926803 +/qpid/branches/java-network-refactor:805429-825319 - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:commits-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-3331) 0.12 release tasks
0.12 release tasks -- Key: QPID-3331 URL: https://issues.apache.org/jira/browse/QPID-3331 Project: Qpid Issue Type: Task Components: Packaging Affects Versions: 0.11 Reporter: Justin Ross - Branching for release (http://svn.apache.org/viewvc?rev=1141543view=rev) - Updating version numbers -- 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: svn commit: r1141543 - /qpid/branches/0.12/
On Thu, Jun 30, 2011 at 10:38 AM, Justin Ross jr...@redhat.com wrote: Good idea. I'll use that for the upcoming version number changes. Nice ! Justin On Thu, 30 Jun 2011, Rajith Attapattu wrote: This is just an idea. Instead of using NO-JIRA we could create a JIRA for 0.12 and then use that for all administrative commits related to 0.12 Ex. creating the branch, creating tags or even use that as a secondary JIRA when porting changes from trunk to release branch. The advantage here is, that there is a single place which gives you a list of all the (administrative) commits related to a particular release. It certainly provides a nice audit trail and gives the release manager an easy way to keep track of all changes going into the release branch. Regards, Rajith On Thu, Jun 30, 2011 at 10:02 AM, jr...@apache.org wrote: Author: jross Date: Thu Jun 30 14:02:01 2011 New Revision: 1141543 URL: http://svn.apache.org/viewvc?rev=1141543view=rev Log: NO-JIRA: Branch for the 0.12 release Added: qpid/branches/0.12/ (props changed) - copied from r1141493, qpid/trunk/ Propchange: qpid/branches/0.12/ -- --- svn:mergeinfo (added) +++ svn:mergeinfo Thu Jun 30 14:02:01 2011 @@ -0,0 +1,3 @@ +/qpid/branches/0.5.x-dev:892761,894875 +/qpid/branches/0.6-release-windows-installer:926803 +/qpid/branches/java-network-refactor:805429-825319 - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:commits-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Synchronous I/O in Ruby client...
On Thu, Jun 30, 2011 at 03:05:52PM +0100, Alan Conway wrote: I'd like to see something like: - a thread safe get next event call that returns events for message delivery, async responses and any other triggers coming from the broker I definitely like the sound of this. - a file descriptor that is readable whenever there are qpid events pending so you can knit this into a poll/epoll/select loop - an ease-of-use layer that provides ready-made thread pool implementations of common dispatch policies e.g. message listeners, thread-per-connection, thread-per-session, thread-per-message etc. The ruby integration would use the lower level event handling API to dispatch qpid events in ruby threads in whatever way is appropriate and avoid blocking calls entirely. Obviously we're not there yet but I think we will eventually move in that direction. Given that I'm still fairly new to the team, how far off does that seem on our roadmap? -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpqBrEYF6g1h.pgp Description: PGP signature
Re: Synchronous I/O in Ruby client...
On 06/30/2011 03:49 PM, Darryl L. Pierce wrote: On Thu, Jun 30, 2011 at 03:05:52PM +0100, Alan Conway wrote: I'd like to see something like: - a thread safe get next event call that returns events for message delivery, async responses and any other triggers coming from the broker I definitely like the sound of this. - a file descriptor that is readable whenever there are qpid events pending so you can knit this into a poll/epoll/select loop - an ease-of-use layer that provides ready-made thread pool implementations of common dispatch policies e.g. message listeners, thread-per-connection, thread-per-session, thread-per-message etc. The ruby integration would use the lower level event handling API to dispatch qpid events in ruby threads in whatever way is appropriate and avoid blocking calls entirely. Obviously we're not there yet but I think we will eventually move in that direction. Given that I'm still fairly new to the team, how far off does that seem on our roadmap? I would like to make some progress on this in the Qpid 0.14 timescale. Being API related it will likely take a bit of discussion to arrive at something stable so I wouldn't count on anything solid appearing in the very short term. We should at least make a start though. It has come up in numerous different contexts (Cliff has indicated that without this WCF couldn't be efficiently implemented on top of the messaging API requiring it to use internal mechanisms; Kerry raised the issue with polling in a thread on failover notification yesterday; etc etc). - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Qpid specific properties for retrieving information
We currently have several Qpid specific props for retrieving information from messages. They provide a nice extension point to retrieve various information that is otherwise not exposed in standard methods. For example, with the JMS client, some folks would like to retrieve the routing-key the message was sent, or the subject or content-type ..etc There are no standard JMS methods for these, but we can leverage the **interface** provided for setting/getting application properties. The Qpid API also provides a similar abstraction. It would be nice if we document these properties used and enforce some sort of naming convention. Sharing and documenting these props will help ensure that all clients support it to provide a uniform experience to our end users. 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 2. For retrieving Qpid specific information (Ex the routing-key.) qpid.property-name Ex qpid.subject Regards, Rajith [1] https://cwiki.apache.org/confluence/display/qpid/Qpid+specific+props+for+retrieving+information. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: svn commit: r1141543 - /qpid/branches/0.12/
I think that is a good idea for general administrative tasks, and it has certainly been suggested by others in the past. However I think it is a bad idea for merges: those should all be tagged with the original JIRA, just like the commit being merged should already be. Robbie On 30 June 2011 15:25, Rajith Attapattu rajit...@gmail.com wrote: This is just an idea. Instead of using NO-JIRA we could create a JIRA for 0.12 and then use that for all administrative commits related to 0.12 Ex. creating the branch, creating tags or even use that as a secondary JIRA when porting changes from trunk to release branch. The advantage here is, that there is a single place which gives you a list of all the (administrative) commits related to a particular release. It certainly provides a nice audit trail and gives the release manager an easy way to keep track of all changes going into the release branch. Regards, Rajith On Thu, Jun 30, 2011 at 10:02 AM, jr...@apache.org wrote: Author: jross Date: Thu Jun 30 14:02:01 2011 New Revision: 1141543 URL: http://svn.apache.org/viewvc?rev=1141543view=rev Log: NO-JIRA: Branch for the 0.12 release Added: qpid/branches/0.12/ (props changed) - copied from r1141493, qpid/trunk/ Propchange: qpid/branches/0.12/ -- --- svn:mergeinfo (added) +++ svn:mergeinfo Thu Jun 30 14:02:01 2011 @@ -0,0 +1,3 @@ +/qpid/branches/0.5.x-dev:892761,894875 +/qpid/branches/0.6-release-windows-installer:926803 +/qpid/branches/java-network-refactor:805429-825319 - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:commits-subscr...@qpid.apache.org - 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: svn commit: r1141543 - /qpid/branches/0.12/
On Thu, Jun 30, 2011 at 12:46 PM, Robbie Gemmell robbie.gemm...@gmail.com wrote: I think that is a good idea for general administrative tasks, and it has certainly been suggested by others in the past. However I think it is a bad idea for merges: those should all be tagged with the original JIRA, just like the commit being merged should already be. I was suggesting to use it as a secondary JIRA (alongside the original). That way the release specific JIRA would have a record in addition the to original JIRA. IIRC you can put several JIRAs in the commit message and JIRA/SVN is able to recognize them and add references accordingly. It doesn't hurt to have record of what exactly was ported into the release branch. Rajith Robbie On 30 June 2011 15:25, Rajith Attapattu rajit...@gmail.com wrote: This is just an idea. Instead of using NO-JIRA we could create a JIRA for 0.12 and then use that for all administrative commits related to 0.12 Ex. creating the branch, creating tags or even use that as a secondary JIRA when porting changes from trunk to release branch. The advantage here is, that there is a single place which gives you a list of all the (administrative) commits related to a particular release. It certainly provides a nice audit trail and gives the release manager an easy way to keep track of all changes going into the release branch. Regards, Rajith On Thu, Jun 30, 2011 at 10:02 AM, jr...@apache.org wrote: Author: jross Date: Thu Jun 30 14:02:01 2011 New Revision: 1141543 URL: http://svn.apache.org/viewvc?rev=1141543view=rev Log: NO-JIRA: Branch for the 0.12 release Added: qpid/branches/0.12/ (props changed) - copied from r1141493, qpid/trunk/ Propchange: qpid/branches/0.12/ -- --- svn:mergeinfo (added) +++ svn:mergeinfo Thu Jun 30 14:02:01 2011 @@ -0,0 +1,3 @@ +/qpid/branches/0.5.x-dev:892761,894875 +/qpid/branches/0.6-release-windows-installer:926803 +/qpid/branches/java-network-refactor:805429-825319 - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:commits-subscr...@qpid.apache.org - 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 - 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 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. 2. For retrieving Qpid specific information (Ex the routing-key.) qpid.property-name Ex qpid.subject Regards, Rajith [1]https://cwiki.apache.org/confluence/display/qpid/Qpid+specific+props+for+retrieving+information. Why not just add this table to the Programming Guide, e.g. in the mapping to AMQP 0-10? - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3332) Occasional test failures from TransactionTimeoutTest user default test profile under Jenkins
Occasional test failures from TransactionTimeoutTest user default test profile
under Jenkins
Key: QPID-3332
URL: https://issues.apache.org/jira/browse/QPID-3332
Project: Qpid
Issue Type: Bug
Components: Java Tests
Affects Versions: 0.10
Reporter: Keith Wall
Assignee: Keith Wall
Priority: Minor
Fix For: Future
We have a longstanding problem that sees occasional test failures from
TransactionTimeoutTest under the default test profile under Jenkins CI. The
test failures are:
{code}
junit.framework.AssertionFailedError: Expected 0 but found 1 txn idle messages
at
org.apache.qpid.test.unit.transacted.TransactionTimeoutTestCase.monitor(TransactionTimeoutTestCase.java:197)
at
org.apache.qpid.test.unit.transacted.TransactionTimeoutTest.testProducerOpenCommit(TransactionTimeoutTest.java:86)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.runBare(QpidBrokerTestCase.java:234)
at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:120)
{code}
and
{code}
junit.framework.AssertionFailedError: Expected 10 but found 6 txn idle messages
at
org.apache.qpid.test.unit.transacted.TransactionTimeoutTestCase.monitor(TransactionTimeoutTestCase.java:201)
at
org.apache.qpid.test.unit.transacted.TransactionTimeoutTest.testProducerIdleRollbackTwice(TransactionTimeoutTest.java:187)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.runBare(QpidBrokerTestCase.java:234)
at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:120)
{code}
This problem caused the following builds to fail: 146, 147, 148, 152, 161, and
162.
https://builds.apache.org/view/M-R/view/Qpid/job/qpid-java-build/147/
--
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-3332) Occasional test failures from TransactionTimeoutTest under default test profile under Jenkins
[
https://issues.apache.org/jira/browse/QPID-3332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-3332:
-
Summary: Occasional test failures from TransactionTimeoutTest under default
test profile under Jenkins (was: Occasional test failures from
TransactionTimeoutTest user default test profile under Jenkins)
Occasional test failures from TransactionTimeoutTest under default test
profile under Jenkins
-
Key: QPID-3332
URL: https://issues.apache.org/jira/browse/QPID-3332
Project: Qpid
Issue Type: Bug
Components: Java Tests
Affects Versions: 0.10
Reporter: Keith Wall
Assignee: Keith Wall
Priority: Minor
Labels: CI, Jenkins
Fix For: Future
We have a longstanding problem that sees occasional test failures from
TransactionTimeoutTest under the default test profile under Jenkins CI. The
test failures are:
{code}
junit.framework.AssertionFailedError: Expected 0 but found 1 txn idle messages
at
org.apache.qpid.test.unit.transacted.TransactionTimeoutTestCase.monitor(TransactionTimeoutTestCase.java:197)
at
org.apache.qpid.test.unit.transacted.TransactionTimeoutTest.testProducerOpenCommit(TransactionTimeoutTest.java:86)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.runBare(QpidBrokerTestCase.java:234)
at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:120)
{code}
and
{code}
junit.framework.AssertionFailedError: Expected 10 but found 6 txn idle
messages
at
org.apache.qpid.test.unit.transacted.TransactionTimeoutTestCase.monitor(TransactionTimeoutTestCase.java:201)
at
org.apache.qpid.test.unit.transacted.TransactionTimeoutTest.testProducerIdleRollbackTwice(TransactionTimeoutTest.java:187)
at
org.apache.qpid.test.utils.QpidBrokerTestCase.runBare(QpidBrokerTestCase.java:234)
at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:120)
{code}
This problem caused the following builds to fail: 146, 147, 148, 152, 161,
and 162.
https://builds.apache.org/view/M-R/view/Qpid/job/qpid-java-build/147/
--
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 Thu, Jun 30, 2011 at 12:59 PM, Gordon Sim g...@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. 2. For retrieving Qpid specific information (Ex the routing-key.) qpid.property-name Ex qpid.subject Regards, Rajith [1]https://cwiki.apache.org/confluence/display/qpid/Qpid+specific+props+for+retrieving+information. Why not just add this table to the Programming Guide, e.g. in the mapping to AMQP 0-10? That is the goal - the wiki page was just to collect all the props. In a couple of days I will add this to the programming guide. Rajith - 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-3333) Make Python SWIG bindings a drop-in replacement for pure Python qpid.messaging package
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 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
[jira] [Updated] (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:all-tabpanel ] Anthony Foglia updated QPID-: - Attachment: 0006-Change-Message-interface-to-match-pure-python.patch 0005-Change-Sender-interface-to-match-pure-python.patch 0004-Change-Receiver-interface-to-match-pure-python.patch 0003-Change-Session-interface-to-match-pure-python.patch 0002-Change-Connection-interface-to-match-pure-python.patch 0001-Wrap-NoMessageAvailable-as-Empty-exception.patch These patches are my progress so far in aligning the two APIs. It's not perfect, but it's good enough to cover our current use case. It's ready for wider testing, and any other advice on getting these patches in the next version. Among the areas that still need improvement: * Exceptions: Only the NoMessagesFound - Empty translation is currently done. And no work has been done on building a heirarchy as in the pure Python API * Dispositions: No work has been done. Trying to use them will throw an exception. They only affect cpp/bindings/qpid/python/python.i file, so nothing but the Python SWIG wrappers will be affected. 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: Keep better track of threads avoiding deadlocks at process rundown
On 2011-06-16 12:56:46, Alan Conway wrote: /trunk/qpid/cpp/src/qpid/sys/windows/Thread.cpp, line 85 https://reviews.apache.org/r/904/diff/1/?file=21139#file21139line85 Why the pointer? Just declare std::mapunsigned, ThreadPrivate::shared_ptr pQpidThreads; and let std::map take care of the memory management. Andrew Stitcher wrote: I'd also add that we don't use the hungarian variable notation either so the 'p' should be stripped (possibly from other places too) OK... this was previously invisible because I missed the Publish step :-( The intended logic was that Thread::current() should have defined behavior, even if called from a static destructor. Otherwise, you need a way to guarantee the std:map destructor is never called too soon. The original JIRA's deadlock was in the context of a static destructor calling Thread::join(). On re-examiniation, the use of a non-POD lock mechanism is inconsistent with the stated goal. Thank-you for the heads up. I will work with Steve to address this and the naming problem. I have a fixed version I will upload to a separate review... coming soon. - Cliff --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/904/#review849 --- 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=13058032#comment-13058032 ] jirapos...@reviews.apache.org commented on QPID-3256: - bq. On 2011-06-16 12:56:46, Alan Conway wrote: bq. /trunk/qpid/cpp/src/qpid/sys/windows/Thread.cpp, line 85 bq. https://reviews.apache.org/r/904/diff/1/?file=21139#file21139line85 bq. bq. Why the pointer? Just declare bq. bq. std::mapunsigned, ThreadPrivate::shared_ptr pQpidThreads; bq. bq. and let std::map take care of the memory management. bq. bq. Andrew Stitcher wrote: bq. I'd also add that we don't use the hungarian variable notation either so the 'p' should be stripped (possibly from other places too) OK... this was previously invisible because I missed the Publish step :-( The intended logic was that Thread::current() should have defined behavior, even if called from a static destructor. Otherwise, you need a way to guarantee the std:map destructor is never called too soon. The original JIRA's deadlock was in the context of a static destructor calling Thread::join(). On re-examiniation, the use of a non-POD lock mechanism is inconsistent with the stated goal. Thank-you for the heads up. I will work with Steve to address this and the naming problem. I have a fixed version I will upload to a separate review... coming soon. - Cliff --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/904/#review849 --- 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
Re: svn commit: r1141543 - /qpid/branches/0.12/
On 30 June 2011 21:10, Robbie Gemmell robbie.gemm...@gmail.com wrote: On 30 June 2011 17:56, Rajith Attapattu rajit...@gmail.com wrote: On Thu, Jun 30, 2011 at 12:46 PM, Robbie Gemmell robbie.gemm...@gmail.com wrote: I think that is a good idea for general administrative tasks, and it has certainly been suggested by others in the past. However I think it is a bad idea for merges: those should all be tagged with the original JIRA, just like the commit being merged should already be. I was suggesting to use it as a secondary JIRA (alongside the original). That way the release specific JIRA would have a record in addition the to original JIRA. Apologies, I somehow completely missed the 'secondary' in there originally, oops :) IIRC you can put several JIRAs in the commit message and JIRA/SVN is able to recognize them and add references accordingly. It doesn't hurt to have record of what exactly was ported into the release branch. Rajith You certainly can add multiple JIRA references to a commit, although in my eyes the original JIRAs already should be the record of what was ported to the release branch as we have previously created the release version number in JIRA and used it for that purpose once branched for release. Which I have incidentally now done ;) Justin, I also added your JIRA account to the Cmmitters role while I was in there. Robbie Robbie Robbie On 30 June 2011 15:25, Rajith Attapattu rajit...@gmail.com wrote: This is just an idea. Instead of using NO-JIRA we could create a JIRA for 0.12 and then use that for all administrative commits related to 0.12 Ex. creating the branch, creating tags or even use that as a secondary JIRA when porting changes from trunk to release branch. The advantage here is, that there is a single place which gives you a list of all the (administrative) commits related to a particular release. It certainly provides a nice audit trail and gives the release manager an easy way to keep track of all changes going into the release branch. Regards, Rajith On Thu, Jun 30, 2011 at 10:02 AM, jr...@apache.org wrote: Author: jross Date: Thu Jun 30 14:02:01 2011 New Revision: 1141543 URL: http://svn.apache.org/viewvc?rev=1141543view=rev Log: NO-JIRA: Branch for the 0.12 release Added: qpid/branches/0.12/ (props changed) - copied from r1141493, qpid/trunk/ Propchange: qpid/branches/0.12/ -- --- svn:mergeinfo (added) +++ svn:mergeinfo Thu Jun 30 14:02:01 2011 @@ -0,0 +1,3 @@ +/qpid/branches/0.5.x-dev:892761,894875 +/qpid/branches/0.6-release-windows-installer:926803 +/qpid/branches/java-network-refactor:805429-825319 - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:commits-subscr...@qpid.apache.org - 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 - 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: svn commit: r1141543 - /qpid/branches/0.12/
On 30 June 2011 17:56, Rajith Attapattu rajit...@gmail.com wrote: On Thu, Jun 30, 2011 at 12:46 PM, Robbie Gemmell robbie.gemm...@gmail.com wrote: I think that is a good idea for general administrative tasks, and it has certainly been suggested by others in the past. However I think it is a bad idea for merges: those should all be tagged with the original JIRA, just like the commit being merged should already be. I was suggesting to use it as a secondary JIRA (alongside the original). That way the release specific JIRA would have a record in addition the to original JIRA. Apologies, I somehow completely missed the 'secondary' in there originally, oops :) IIRC you can put several JIRAs in the commit message and JIRA/SVN is able to recognize them and add references accordingly. It doesn't hurt to have record of what exactly was ported into the release branch. Rajith You certainly can add multiple JIRA references to a commit, although in my eyes the original JIRAs already should be the record of what was ported to the release branch as we have previously created the release version number in JIRA and used it for that purpose once branched for release. Robbie Robbie On 30 June 2011 15:25, Rajith Attapattu rajit...@gmail.com wrote: This is just an idea. Instead of using NO-JIRA we could create a JIRA for 0.12 and then use that for all administrative commits related to 0.12 Ex. creating the branch, creating tags or even use that as a secondary JIRA when porting changes from trunk to release branch. The advantage here is, that there is a single place which gives you a list of all the (administrative) commits related to a particular release. It certainly provides a nice audit trail and gives the release manager an easy way to keep track of all changes going into the release branch. Regards, Rajith On Thu, Jun 30, 2011 at 10:02 AM, jr...@apache.org wrote: Author: jross Date: Thu Jun 30 14:02:01 2011 New Revision: 1141543 URL: http://svn.apache.org/viewvc?rev=1141543view=rev Log: NO-JIRA: Branch for the 0.12 release Added: qpid/branches/0.12/ (props changed) - copied from r1141493, qpid/trunk/ Propchange: qpid/branches/0.12/ -- --- svn:mergeinfo (added) +++ svn:mergeinfo Thu Jun 30 14:02:01 2011 @@ -0,0 +1,3 @@ +/qpid/branches/0.5.x-dev:892761,894875 +/qpid/branches/0.6-release-windows-installer:926803 +/qpid/branches/java-network-refactor:805429-825319 - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:commits-subscr...@qpid.apache.org - 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 - 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] [Closed] (QPID-3334) Missing file causes distcheck failure
[ https://issues.apache.org/jira/browse/QPID-3334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross closed QPID-3334. - Resolution: Fixed Missing file causes distcheck failure - Key: QPID-3334 URL: https://issues.apache.org/jira/browse/QPID-3334 Project: Qpid Issue Type: Bug Components: Packaging Affects Versions: 0.12 Reporter: Justin Ross Assignee: Justin Ross Priority: Blocker Fix For: 0.12 The C++ broker's distribution is missing a file reference. -- 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: svn commit: r1141543 - /qpid/branches/0.12/
On Thu, 30 Jun 2011, Robbie Gemmell wrote: Justin, I also added your JIRA account to the Cmmitters role while I was in there. Robbie Ah, thanks! I was about to request that. Justin Robbie Robbie On 30 June 2011 15:25, Rajith Attapattu rajit...@gmail.com wrote: This is just an idea. Instead of using NO-JIRA we could create a JIRA for 0.12 and then use that for all administrative commits related to 0.12 Ex. creating the branch, creating tags or even use that as a secondary JIRA when porting changes from trunk to release branch. The advantage here is, that there is a single place which gives you a list of all the (administrative) commits related to a particular release. It certainly provides a nice audit trail and gives the release manager an easy way to keep track of all changes going into the release branch. Regards, Rajith On Thu, Jun 30, 2011 at 10:02 AM, jr...@apache.org wrote: Author: jross Date: Thu Jun 30 14:02:01 2011 New Revision: 1141543 URL: http://svn.apache.org/viewvc?rev=1141543view=rev Log: NO-JIRA: Branch for the 0.12 release Added: qpid/branches/0.12/ (props changed) - copied from r1141493, qpid/trunk/ Propchange: qpid/branches/0.12/ -- --- svn:mergeinfo (added) +++ svn:mergeinfo Thu Jun 30 14:02:01 2011 @@ -0,0 +1,3 @@ +/qpid/branches/0.5.x-dev:892761,894875 +/qpid/branches/0.6-release-windows-installer:926803 +/qpid/branches/java-network-refactor:805429-825319 - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:commits-subscr...@qpid.apache.org - 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 - 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 - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
0.12 release update - release branch created, beta available
Hi. I created the release branch this morning at revision 1141543. Some testing revealed a problem in the C++ source distribution, so I fixed that (with Mick's help) and cut the beta from revision 1141708 on the release branch. Get it at http://people.apache.org/~jross/qpid-0.12-beta/ I believe that I've also corrected all the version numbers on trunk and the release branch, to 0.13 and 0.12 respectively. Please let me know if I missed one. I'm keeping a list of files containing version numbers at https://cwiki.apache.org/confluence/display/qpid/Source+files+containing+version+numbers I still need to produce the bug summary, but you can see all the raw information at the jira links on the release page. The next item on the schedule is RC1, in two weeks. If you've been waiting, now is the time to jump in and evaluate the code that will become Qpid 0.12. Thanks, Justin --- 0.12 release page: https://cwiki.apache.org/confluence/display/qpid/0.12+Release - 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=13058197#comment-13058197
]
jirapos...@reviews.apache.org commented on QPID-3256:
-
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/987/
---
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
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,
unsigned long dwReason=0, void * lpreserved=0x) Line 510 + 0x11
bytes C
ntdll.dll!77b79960()
[Frames below may be incorrect and/or missing, no symbols loaded for
ntdll.dll]
ntdll.dll!77ba1525()
ntdll.dll!77b81231()
KernelBase.dll!77281da7()
ole32.dll!75bb9562()
ole32.dll!75bb9593()
ole32.dll!75bb95a7()
ole32.dll!75bb98bf()
ole32.dll!75bb9805()
ole32.dll!75bb9a8c()
