RE: 0.32 release update - RC is available
qpid-cpp is ok on AIX. > -Original Message- > From: Justin Ross [mailto:justin.r...@gmail.com] > Sent: Tuesday, March 10, 2015 9:22 AM > To: users@qpid.apache.org > Subject: 0.32 release update - RC is available > > Hi, folks. The 0.32 release candidate is now available. > > Release artifacts: https://dist.apache.org/repos/dist/dev/qpid/0.32-rc/ > Maven staging repo: > https://repository.apache.org/content/repositories/orgapacheqpid-1027 > Test output: http://people.apache.org/~jross/qpid-0.32-rc.log > > This is pre-release code, for testing only! Thanks very much to those who > have reported on their testing thus far. Please verify that the RC works for > you. > > Note that the ssl_test failure in the cpp test output is a still unresolved > problem with my test harness. The test succeeds when I run it manually. > > These release artifacts are signed. If approved by vote, the RC bits will be > the GA bits. I will open the vote later today. > > Thanks! > Justin > > --- > 0.32 release page: > https://cwiki.apache.org/confluence/display/qpid/0.32+Release
Re: 0.32 release update - RC is available
Justin, I tested 0.32 RC java broker and java JMS clients by starting the broker and running Hello/Spout/Drain examples from 0.8/0.9.x/0.10 JMS client and Hello example from 1.0 JMS client. They worked fine for me. No issue is found. Additionally I tested web management console operations like creation and editing of virtual host nodes,virtual hosts, groups providers, acl provider, port, etc. No issue is found there as well. Kind Regards, Alex On 10 March 2015 at 13:21, Justin Ross wrote: > Hi, folks. The 0.32 release candidate is now available. > > Release artifacts: https://dist.apache.org/repos/dist/dev/qpid/0.32-rc/ > Maven staging repo: > https://repository.apache.org/content/repositories/orgapacheqpid-1027 > Test output: http://people.apache.org/~jross/qpid-0.32-rc.log > > This is pre-release code, for testing only! Thanks very much to those who > have reported on their testing thus far. Please verify that the RC works > for you. > > Note that the ssl_test failure in the cpp test output is a still unresolved > problem with my test harness. The test succeeds when I run it manually. > > These release artifacts are signed. If approved by vote, the RC bits will > be the GA bits. I will open the vote later today. > > Thanks! > Justin > > --- > 0.32 release page: > https://cwiki.apache.org/confluence/display/qpid/0.32+Release >
RE: Images transfer
Yes. > -Original Message- > From: Michael Ivanov [mailto:iv...@logit-ag.de] > Sent: Tuesday, March 10, 2015 4:52 PM > To: users@qpid.apache.org > Subject: Images transfer > > Good evening, > > Is it reasonable to use amqp messages (currently I am using proton together > with qpidd) for image transfer? The images are expected to be of 1 ... 1.5Mb > size. > > Best regards, > -- > \ / | | > (OvO) | Mikhail Iwanow | > (^^^) | Voice: +7 (911) 223-1300 | > \^/ | E-mail: iv...@logit-ag.de | > ^ ^ | | > > - > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional > commands, e-mail: users-h...@qpid.apache.org
Re: 0.32 release update - RC is available
I've made a fix as https://svn.apache.org/r1665702 on trunk. The impact of the change is solely to the automatic upgrader, and specifically only for the path that is currently causing the error (key/trust stores where the default type was previously being used in the config). -- Rob On 10 March 2015 at 22:17, Rob Godfrey wrote: > We have an error report from a user of the Java broker here: > https://issues.apache.org/jira/browse/QPID-6439 > > The fix will be trivial, but since it will mean anyone upgrading from > 0.30 or earlier to 0.32 will not be able to start their broker after > upgrading, I'd like to get a fix in for this. > > -- Rob > > On 10 March 2015 at 14:21, Justin Ross wrote: >> Hi, folks. The 0.32 release candidate is now available. >> >> Release artifacts: https://dist.apache.org/repos/dist/dev/qpid/0.32-rc/ >> Maven staging repo: >> https://repository.apache.org/content/repositories/orgapacheqpid-1027 >> Test output: http://people.apache.org/~jross/qpid-0.32-rc.log >> >> This is pre-release code, for testing only! Thanks very much to those who >> have reported on their testing thus far. Please verify that the RC works >> for you. >> >> Note that the ssl_test failure in the cpp test output is a still unresolved >> problem with my test harness. The test succeeds when I run it manually. >> >> These release artifacts are signed. If approved by vote, the RC bits will >> be the GA bits. I will open the vote later today. >> >> Thanks! >> Justin >> >> --- >> 0.32 release page: >> https://cwiki.apache.org/confluence/display/qpid/0.32+Release - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Images transfer
Good evening, Is it reasonable to use amqp messages (currently I am using proton together with qpidd) for image transfer? The images are expected to be of 1 ... 1.5Mb size. Best regards, -- \ / | | (OvO) | Mikhail Iwanow | (^^^) | Voice: +7 (911) 223-1300 | \^/ | E-mail: iv...@logit-ag.de | ^ ^ | | - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: VOTE: Release Proton 0.9-rc-1 as 0.9 final
Hi Everyone, FYI, I'm going to be out of contact for a few days again. So far the two issues discovered in this RC are quite isolated, so please continue to test RC 1 and make sure any new fixes go on the 0.9 branch. I will spin another RC off of the branch as soon as I'm back. Thanks, --Rafael On Tue, Mar 10, 2015 at 12:57 AM, Rafael Schloming wrote: > Hi Everyone, > > I've posted 0.9-rc-1 in the usual places. Please have a look and register > your vote: > > Source code can be found here: > > http://people.apache.org/~rhs/qpid-proton-0.9-rc-1/ > > Java binaries are here: > > https://repository.apache.org/content/repositories/orgapacheqpid-1025 > > [ ] Yes, release Proton 0.9-rc-1 as 0.9 final > [ ] No, because ... > --Rafael >
Re: proton application context API deprecated in 0.9?
- Original Message - > From: "Rafael Schloming" > To: users@qpid.apache.org > Sent: Tuesday, March 10, 2015 6:44:29 AM > Subject: Re: proton application context API deprecated in 0.9? > > On Mon, Mar 9, 2015 at 4:11 PM, Ken Giusti wrote: > > > Hi Rafi - thank you for that description. I'll have to dig into that code > > a bit more to get a feel for it. > > > > The only concern I have is the implementation of PN_HANDLE. If I'm > > correct, you can't directly share PN_HANDLE's across compilation units due > > to the use of static variables. In other words, if I have > > > > PN_HANDLE(RAFI); > > > > in my rafi_private.h header, each compilation unit will define a RAFI > > handle with a different underlying value. > > > > That's a good point, however it shouldn't be a problem for the intended > usage because the macro would never ever appear in a .h file, only .c files. > But nothing (currently) prevents doing that, unless you've spent time reading the header files and understand the implementation. Speaking personally, it would be better to idiot proof this :) > > > Since it's not a compilation-time error, this could result in a very hard > > to diagnose run time bug. > > > > Perhaps a simple #defined constant would be safer? > > > > The trouble with using a simple constant is that two independent pieces of > code might end up choosing the same constant resulting in similarly subtle > bugs. The PN_HANDLE macro gives independent pieces of code a way to define > guaranteed unique constants without having to depend on some sort of > central allocation strategy that needs to be initialized. The language > runtime provides the guarantees based on memory location. > > I think if you follow the best practice strategy of always defining > pn_xxx_get/set_foo accessors, then not only will your code be type safe, > but you should also never need to use a handle outside of the one > compilation unit that defines the accessors. This would even be a good idea > if you were using simple #define constants since you would have a much > safer ABI. We could probably even enforce this pattern by putting something > in the macro that would barf if you were to ever stick it in a .h file and > include it twice. (Maybe even just making the declarations non-static would > be sufficient.) > I'm good with simply changing the definition of PN_HANDLE() slightly: #define PN_HANDLE(name) \ static char *_PN_HANDLE_ ## name = 0; \ const pn_handle_t name = ((pn_handle_t) &_PN_HANDLE_ ## name); so there's at least link-time enforcement of the singleton (and error messages will complain about $name, not _PN_HANDLE_$name). If you wanted to be even more explicit as to the pattern, you could add the following: #define PN_HANDLE_EXTERN(name) extern const pn_handle_t name; which would be an additional usage hint. > --Rafael > -- -K - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
0.32 release update - RC is available
Hi, folks. The 0.32 release candidate is now available. Release artifacts: https://dist.apache.org/repos/dist/dev/qpid/0.32-rc/ Maven staging repo: https://repository.apache.org/content/repositories/orgapacheqpid-1027 Test output: http://people.apache.org/~jross/qpid-0.32-rc.log This is pre-release code, for testing only! Thanks very much to those who have reported on their testing thus far. Please verify that the RC works for you. Note that the ssl_test failure in the cpp test output is a still unresolved problem with my test harness. The test succeeds when I run it manually. These release artifacts are signed. If approved by vote, the RC bits will be the GA bits. I will open the vote later today. Thanks! Justin --- 0.32 release page: https://cwiki.apache.org/confluence/display/qpid/0.32+Release
Re: handling old Subversion contents after migrations to Git
+1 for option 3 On 9 March 2015 at 16:24, Robbie Gemmell wrote: > Hi all, > > As you probably know, we migrated the Proton and new JMS client code > to Git repositories last year. As part of the process the old > locations within the Subversion repo were frozen read-only and left in > place. > > Some folks have been caught out by using the old stale locations, as > although we have updated our website with the new locations (and all > the commits@ traffic mentions the new locations) it isnt particularly > clear from the old contents themselves that they are no longer in use > (other than by realising the last commits were a while ago). > > I noticed some documentation which indicated as Chair I should be able > to modify the access rights to the old locations, allowing us to edit > them and make things clearer. I checked with infra and that is indeed > the case, although they are also happy to do it for us depending on > the change (e.g move contents to an attic dir, add pointer file). > > I wonder what people think we should do: > 1. Add pointer files indicating the contents are no longer used and > directing to the Git repos. > 2. Delete the trunk dirs, add pointer files to the Git repos. > 3. Move the contents to an attic area, add pointer files to the Git > repos in old locations. > 4. Delete the contents entirely, dont add pointers. > > (The 'deleted' files will obviously remain in Subversion history) > > Thoughts? > > Thanks, > Robbie > > - > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
Re: proton application context API deprecated in 0.9?
On Mon, Mar 9, 2015 at 4:11 PM, Ken Giusti wrote: > Hi Rafi - thank you for that description. I'll have to dig into that code > a bit more to get a feel for it. > > The only concern I have is the implementation of PN_HANDLE. If I'm > correct, you can't directly share PN_HANDLE's across compilation units due > to the use of static variables. In other words, if I have > > PN_HANDLE(RAFI); > > in my rafi_private.h header, each compilation unit will define a RAFI > handle with a different underlying value. > That's a good point, however it shouldn't be a problem for the intended usage because the macro would never ever appear in a .h file, only .c files. > Since it's not a compilation-time error, this could result in a very hard > to diagnose run time bug. > > Perhaps a simple #defined constant would be safer? > The trouble with using a simple constant is that two independent pieces of code might end up choosing the same constant resulting in similarly subtle bugs. The PN_HANDLE macro gives independent pieces of code a way to define guaranteed unique constants without having to depend on some sort of central allocation strategy that needs to be initialized. The language runtime provides the guarantees based on memory location. I think if you follow the best practice strategy of always defining pn_xxx_get/set_foo accessors, then not only will your code be type safe, but you should also never need to use a handle outside of the one compilation unit that defines the accessors. This would even be a good idea if you were using simple #define constants since you would have a much safer ABI. We could probably even enforce this pattern by putting something in the macro that would barf if you were to ever stick it in a .h file and include it twice. (Maybe even just making the declarations non-static would be sufficient.) --Rafael
Re: handling old Subversion contents after migrations to Git
On 9 March 2015 at 16:24, Robbie Gemmell wrote: > Hi all, > > As you probably know, we migrated the Proton and new JMS client code > to Git repositories last year. As part of the process the old > locations within the Subversion repo were frozen read-only and left in > place. > > Some folks have been caught out by using the old stale locations, as > although we have updated our website with the new locations (and all > the commits@ traffic mentions the new locations) it isnt particularly > clear from the old contents themselves that they are no longer in use > (other than by realising the last commits were a while ago). > > I noticed some documentation which indicated as Chair I should be able > to modify the access rights to the old locations, allowing us to edit > them and make things clearer. I checked with infra and that is indeed > the case, although they are also happy to do it for us depending on > the change (e.g move contents to an attic dir, add pointer file). > > I wonder what people think we should do: > 1. Add pointer files indicating the contents are no longer used and > directing to the Git repos. > 2. Delete the trunk dirs, add pointer files to the Git repos. > 3. Move the contents to an attic area, add pointer files to the Git > repos in old locations. > 4. Delete the contents entirely, dont add pointers. > > (The 'deleted' files will obviously remain in Subversion history) > > Thoughts? > > Thanks, > Robbie I should have really added that we dont necessarily have to do the same thing for both areas of code, i.e the new JMS client and Proton. The former had the distinction of having no branches or tags, never having been released, not being particularly usable in the form it was in at the time, and being quite different from what is there these days. For me, Option 3 or 4 make most sense for that old code, I dont expect anyone is looking in there except people randomly broswing the whole Qpid repo. For the Proton code, I'd probably go for options 1,3,2,4 in that order. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
AW: handling old Subversion contents after migrations to Git
+1 for option 1 -Ursprüngliche Nachricht- Von: Robbie Gemmell [mailto:robbie.gemm...@gmail.com] Gesendet: Montag, 9. März 2015 17:25 An: users@qpid.apache.org Betreff: handling old Subversion contents after migrations to Git Hi all, As you probably know, we migrated the Proton and new JMS client code to Git repositories last year. As part of the process the old locations within the Subversion repo were frozen read-only and left in place. Some folks have been caught out by using the old stale locations, as although we have updated our website with the new locations (and all the commits@ traffic mentions the new locations) it isnt particularly clear from the old contents themselves that they are no longer in use (other than by realising the last commits were a while ago). I noticed some documentation which indicated as Chair I should be able to modify the access rights to the old locations, allowing us to edit them and make things clearer. I checked with infra and that is indeed the case, although they are also happy to do it for us depending on the change (e.g move contents to an attic dir, add pointer file). I wonder what people think we should do: 1. Add pointer files indicating the contents are no longer used and directing to the Git repos. 2. Delete the trunk dirs, add pointer files to the Git repos. 3. Move the contents to an attic area, add pointer files to the Git repos in old locations. 4. Delete the contents entirely, dont add pointers. (The 'deleted' files will obviously remain in Subversion history) Thoughts? Thanks, Robbie - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
