You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Justin Ross <ju...@gmail.com> on 2015/02/20 12:39:24 UTC
0.32 release update - Beta is available
Hi, everyone. We have branched for release, and 0.32 beta is now available.
Release branch: https://svn.apache.org/repos/asf/qpid/branches/0.32/
Release artifacts: https://dist.apache.org/repos/dist/dev/qpid/0.32-beta/
Release tool log output:
http://people.apache.org/~jross/qpid-0.32-beta.log
This is pre-release software, for testing only.
Now that we've branched, 0.32 changes require developer review and release
manager approval. See the release page for details. It means as well that
trunk has opened for forward development.
Please test the beta in your environment and report your results on the
list. Thank you very much to those who tested the alpha.
The next planned build is our first RC on March 4th.
Thanks!
Justin
---
0.32 release page:
https://cwiki.apache.org/confluence/display/qpid/0.32+Release
Re: 0.32 release update - Beta is available
Posted by Robbie Gemmell <ro...@gmail.com>.
I built the C++ broker, created a queue using qpid-config, and ran the
HelloWorld example from the new JMS client (not part of this release)
against it.
I built the Java broker, clients etc. I started the the broker (no
vhost issues noticed), added a queue via the web management, then ran
the 0.32-beta AMQP 0-10 and 1.0 JMS client Hello examples against it.
Ok, I missed a bit there, I did some of the above twice when I
realised I had run the 1.0 example against the C++ broker again by
accident, as the Java broker started without an obvious sign of issue
despite being unable to bind its AMQP port. This is only visible via
an 'errored' state listed in the web management, or by the absence of
a line normally in the console output, so as a result its really easy
not to realise you arent running against the broker you think. I did
the same thing yesterday as well when testing something else, its
rather annoying. Gordon raised this as
https://issues.apache.org/jira/browse/QPID-6096 previously.
I built the Java QMF tools (but didnt actually use them) against the
earlier Java build from above.
I ran RAT on the various archive contents. Output is available at:
http://people.apache.org/~robbie/qpid/0.32/beta/
There is a file in the Java tree needing a licence header added (which
I will just do shortly):
qpid-java-0.32-beta/tools/src/main/java/org/apache/qpid/tools/util/ArgumentsParser.java
There is a file in the CPP tree which would have warranted some
LICENCE file changes, but this file was removed through use of a
different mechanism shortly after the beta went out:
qpid-cpp-0.32-beta/CMakeModules/CheckSizeTNativeType.cmake
Robbie
On 20 February 2015 at 11:39, Justin Ross <ju...@gmail.com> wrote:
> Hi, everyone. We have branched for release, and 0.32 beta is now available.
>
> Release branch: https://svn.apache.org/repos/asf/qpid/branches/0.32/
> Release artifacts: https://dist.apache.org/repos/dist/dev/qpid/0.32-beta/
> Release tool log output:
> http://people.apache.org/~jross/qpid-0.32-beta.log
>
> This is pre-release software, for testing only.
>
> Now that we've branched, 0.32 changes require developer review and release
> manager approval. See the release page for details. It means as well that
> trunk has opened for forward development.
>
> Please test the beta in your environment and report your results on the
> list. Thank you very much to those who tested the alpha.
>
> The next planned build is our first RC on March 4th.
>
> Thanks!
> Justin
>
> ---
> 0.32 release page:
> https://cwiki.apache.org/confluence/display/qpid/0.32+Release
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: 0.32 release update - Beta is available
Posted by Justin Ross <ju...@gmail.com>.
No separate RFI needed. Thanks!
On Mon, Mar 9, 2015 at 1:38 PM, Rob Godfrey <ro...@gmail.com> wrote:
> Hi Justin,
>
> yep - i was going to request these changes today - been caught in meetings
> until now.
>
> Do you want a separate RFI mail, or will this do as the request for
> inclusion?
>
> Thanks,
> Rob
>
> On 9 March 2015 at 18:26, Justin Ross <ju...@gmail.com> wrote:
>
> > Rob, I looked around and didn't see these requested anywhere. Do you
> want
> > them for 0.32? I've looked at the changes on QPID-6437 and it seems like
> > all of them should go to 0.32.
> >
> > On Sat, Mar 7, 2015 at 11:21 AM, Robbie Gemmell <
> robbie.gemmell@gmail.com>
> > wrote:
> >
> > > I tried out the changes by applying the 3 commits for QPID-6437 to the
> > > current head of the 0.32 branch and all seemed well.
> > > On 6 Mar 2015 20:54, "Rob Godfrey" <ro...@gmail.com> wrote:
> > >
> > > > OK - I think the latest fix I made (on trunk) should fix this issue.
> > > >
> > > > Since it's the same impact as Gordon's JIRA I think it's a blocker
> and
> > so
> > > > would be grateful if you can try to reproduce on trunk (or by locally
> > > > modifying 0.32 with the change in https://svn.apache.org/r1664714 )
> > > >
> > > > Thanks,
> > > > Rob
> > > >
> > > > On 6 March 2015 at 20:03, Robbie Gemmell <ro...@gmail.com>
> > > wrote:
> > > >
> > > > > On 5 March 2015 at 16:49, Gordon Sim <gs...@redhat.com> wrote:
> > > > > > On 03/05/2015 12:42 PM, Rob Godfrey wrote:
> > > > > >>
> > > > > >> D'oh - my fault... Didn't cover the second case. Applied a
> > further
> > > > fix
> > > > > >> that should remove that deadlock.
> > > > > >
> > > > > >
> > > > > > That seems to fix the receive problems for qpid::messaging.
> > > > > >
> > > > >
> > > > > I hit another earlier against the head of the 0.32 branch a little
> > > while
> > > > > ago:
> > > > > https://issues.apache.org/jira/browse/QPID-6437
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > > > > For additional commands, e-mail: users-help@qpid.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: 0.32 release update - Beta is available
Posted by Rob Godfrey <ro...@gmail.com>.
Hi Justin,
yep - i was going to request these changes today - been caught in meetings
until now.
Do you want a separate RFI mail, or will this do as the request for
inclusion?
Thanks,
Rob
On 9 March 2015 at 18:26, Justin Ross <ju...@gmail.com> wrote:
> Rob, I looked around and didn't see these requested anywhere. Do you want
> them for 0.32? I've looked at the changes on QPID-6437 and it seems like
> all of them should go to 0.32.
>
> On Sat, Mar 7, 2015 at 11:21 AM, Robbie Gemmell <ro...@gmail.com>
> wrote:
>
> > I tried out the changes by applying the 3 commits for QPID-6437 to the
> > current head of the 0.32 branch and all seemed well.
> > On 6 Mar 2015 20:54, "Rob Godfrey" <ro...@gmail.com> wrote:
> >
> > > OK - I think the latest fix I made (on trunk) should fix this issue.
> > >
> > > Since it's the same impact as Gordon's JIRA I think it's a blocker and
> so
> > > would be grateful if you can try to reproduce on trunk (or by locally
> > > modifying 0.32 with the change in https://svn.apache.org/r1664714 )
> > >
> > > Thanks,
> > > Rob
> > >
> > > On 6 March 2015 at 20:03, Robbie Gemmell <ro...@gmail.com>
> > wrote:
> > >
> > > > On 5 March 2015 at 16:49, Gordon Sim <gs...@redhat.com> wrote:
> > > > > On 03/05/2015 12:42 PM, Rob Godfrey wrote:
> > > > >>
> > > > >> D'oh - my fault... Didn't cover the second case. Applied a
> further
> > > fix
> > > > >> that should remove that deadlock.
> > > > >
> > > > >
> > > > > That seems to fix the receive problems for qpid::messaging.
> > > > >
> > > >
> > > > I hit another earlier against the head of the 0.32 branch a little
> > while
> > > > ago:
> > > > https://issues.apache.org/jira/browse/QPID-6437
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > > > For additional commands, e-mail: users-help@qpid.apache.org
> > > >
> > > >
> > >
> >
>
Re: 0.32 release update - Beta is available
Posted by Justin Ross <ju...@gmail.com>.
Rob, I looked around and didn't see these requested anywhere. Do you want
them for 0.32? I've looked at the changes on QPID-6437 and it seems like
all of them should go to 0.32.
On Sat, Mar 7, 2015 at 11:21 AM, Robbie Gemmell <ro...@gmail.com>
wrote:
> I tried out the changes by applying the 3 commits for QPID-6437 to the
> current head of the 0.32 branch and all seemed well.
> On 6 Mar 2015 20:54, "Rob Godfrey" <ro...@gmail.com> wrote:
>
> > OK - I think the latest fix I made (on trunk) should fix this issue.
> >
> > Since it's the same impact as Gordon's JIRA I think it's a blocker and so
> > would be grateful if you can try to reproduce on trunk (or by locally
> > modifying 0.32 with the change in https://svn.apache.org/r1664714 )
> >
> > Thanks,
> > Rob
> >
> > On 6 March 2015 at 20:03, Robbie Gemmell <ro...@gmail.com>
> wrote:
> >
> > > On 5 March 2015 at 16:49, Gordon Sim <gs...@redhat.com> wrote:
> > > > On 03/05/2015 12:42 PM, Rob Godfrey wrote:
> > > >>
> > > >> D'oh - my fault... Didn't cover the second case. Applied a further
> > fix
> > > >> that should remove that deadlock.
> > > >
> > > >
> > > > That seems to fix the receive problems for qpid::messaging.
> > > >
> > >
> > > I hit another earlier against the head of the 0.32 branch a little
> while
> > > ago:
> > > https://issues.apache.org/jira/browse/QPID-6437
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > > For additional commands, e-mail: users-help@qpid.apache.org
> > >
> > >
> >
>
Re: 0.32 release update - Beta is available
Posted by Robbie Gemmell <ro...@gmail.com>.
I tried out the changes by applying the 3 commits for QPID-6437 to the
current head of the 0.32 branch and all seemed well.
On 6 Mar 2015 20:54, "Rob Godfrey" <ro...@gmail.com> wrote:
> OK - I think the latest fix I made (on trunk) should fix this issue.
>
> Since it's the same impact as Gordon's JIRA I think it's a blocker and so
> would be grateful if you can try to reproduce on trunk (or by locally
> modifying 0.32 with the change in https://svn.apache.org/r1664714 )
>
> Thanks,
> Rob
>
> On 6 March 2015 at 20:03, Robbie Gemmell <ro...@gmail.com> wrote:
>
> > On 5 March 2015 at 16:49, Gordon Sim <gs...@redhat.com> wrote:
> > > On 03/05/2015 12:42 PM, Rob Godfrey wrote:
> > >>
> > >> D'oh - my fault... Didn't cover the second case. Applied a further
> fix
> > >> that should remove that deadlock.
> > >
> > >
> > > That seems to fix the receive problems for qpid::messaging.
> > >
> >
> > I hit another earlier against the head of the 0.32 branch a little while
> > ago:
> > https://issues.apache.org/jira/browse/QPID-6437
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >
>
Re: 0.32 release update - Beta is available
Posted by Rob Godfrey <ro...@gmail.com>.
OK - I think the latest fix I made (on trunk) should fix this issue.
Since it's the same impact as Gordon's JIRA I think it's a blocker and so
would be grateful if you can try to reproduce on trunk (or by locally
modifying 0.32 with the change in https://svn.apache.org/r1664714 )
Thanks,
Rob
On 6 March 2015 at 20:03, Robbie Gemmell <ro...@gmail.com> wrote:
> On 5 March 2015 at 16:49, Gordon Sim <gs...@redhat.com> wrote:
> > On 03/05/2015 12:42 PM, Rob Godfrey wrote:
> >>
> >> D'oh - my fault... Didn't cover the second case. Applied a further fix
> >> that should remove that deadlock.
> >
> >
> > That seems to fix the receive problems for qpid::messaging.
> >
>
> I hit another earlier against the head of the 0.32 branch a little while
> ago:
> https://issues.apache.org/jira/browse/QPID-6437
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: 0.32 release update - Beta is available
Posted by Robbie Gemmell <ro...@gmail.com>.
On 5 March 2015 at 16:49, Gordon Sim <gs...@redhat.com> wrote:
> On 03/05/2015 12:42 PM, Rob Godfrey wrote:
>>
>> D'oh - my fault... Didn't cover the second case. Applied a further fix
>> that should remove that deadlock.
>
>
> That seems to fix the receive problems for qpid::messaging.
>
I hit another earlier against the head of the 0.32 branch a little while ago:
https://issues.apache.org/jira/browse/QPID-6437
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: 0.32 release update - Beta is available
Posted by Gordon Sim <gs...@redhat.com>.
On 03/05/2015 12:42 PM, Rob Godfrey wrote:
> D'oh - my fault... Didn't cover the second case. Applied a further fix
> that should remove that deadlock.
That seems to fix the receive problems for qpid::messaging.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: 0.32 release update - Beta is available
Posted by Rob Godfrey <ro...@gmail.com>.
D'oh - my fault... Didn't cover the second case. Applied a further fix
that should remove that deadlock.
-- Rob
On 5 March 2015 at 13:32, Gordon Sim <gs...@redhat.com> wrote:
> On 03/04/2015 09:51 PM, Rob Godfrey wrote:
>
>> Deadlock issue should be fixed by https://svn.apache.org/r1664160 (on
>> trunk) (https://issues.apache.org/jira/browse/QPID-6433).
>>
>
> I *think* I'm now using the latest, but still get a deadlock. See stack
> dump attached.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
Re: 0.32 release update - Beta is available
Posted by Gordon Sim <gs...@redhat.com>.
On 03/04/2015 09:51 PM, Rob Godfrey wrote:
> Deadlock issue should be fixed by https://svn.apache.org/r1664160 (on
> trunk) (https://issues.apache.org/jira/browse/QPID-6433).
I *think* I'm now using the latest, but still get a deadlock. See stack
dump attached.
Re: 0.32 release update - Beta is available
Posted by Rob Godfrey <ro...@gmail.com>.
Deadlock issue should be fixed by https://svn.apache.org/r1664160 (on
trunk) (https://issues.apache.org/jira/browse/QPID-6433).
If the deadlock was what was ultimately causing your message receipt
problems, this should also fix those.
If that issue still occurs after this fix, can you give me some more
details on how you are testing?
Thanks,
Rob
On 4 March 2015 at 22:38, Rob Godfrey <ro...@gmail.com> wrote:
>
>
> On 4 March 2015 at 22:02, Gordon Sim <gs...@redhat.com> wrote:
>
>> On 02/20/2015 11:39 AM, Justin Ross wrote:
>>
>>> Hi, everyone. We have branched for release, and 0.32 beta is now
>>> available.
>>>
>>> Release branch: https://svn.apache.org/repos/asf/qpid/branches/0.32/
>>> Release artifacts: https://dist.apache.org/repos/
>>> dist/dev/qpid/0.32-beta/
>>> Release tool log output:
>>> http://people.apache.org/~jross/qpid-0.32-beta.log
>>>
>>> This is pre-release software, for testing only.
>>>
>>> Now that we've branched, 0.32 changes require developer review and
>>> release
>>> manager approval. See the release page for details. It means as well
>>> that
>>> trunk has opened for forward development.
>>>
>>> Please test the beta in your environment and report your results on the
>>> list. Thank you very much to those who tested the alpha.
>>>
>>
>> Built and installed qpid-cpp (against latest proton master), java broker,
>> python client, qmf lib and tools.
>>
>> Tests and tools ran fine against c++ broker.
>>
>> Had some issues with the java broker. It now starts with no virtual host
>> defined(?). Meaning that any attempt to connect got an error. (This is
>> after enabling anonymous, as even plain appeared to be disabled by
>> default?). After creating a virtual host, was able to run some tests
>> against it using qpid-cpp clients over both 0-10 and 1.0.
>>
>
> That's odd... The out of the box config should have a virtualhost. Were
> you running a completely fresh install, or were you running with an
> existing config/work directory?
> In terms of authentication, by default PLAIN is no longer enabled over
> non-TLS connections.
>
>
>>
>> There *seems* to be something odd happening when trying to consume
>> messages from a queue. Over 0-10 I only get the messages if I issue a
>> message-flush. Over 1.0 I sometimes can't get any messages out at all. Not
>> sure if this is only when queue was created over 0-10. Even for a queue
>> created through management, I was not getting messages at times after
>> having sent them and had them accepted (switching back to 0-10 and
>> flushing, I could see them all as expected). If the receiver is active
>> before messages are sent (whether through exchanges or direct through
>> queues), receiving seems to work ok.
>>
>> Got a deadlock trying to stop the (java) broker, see attached. On
>> restarting, my virtual host was there but somehow things were corrupted and
>> could not connect again until I deleted and recreated it.
>
>
> So, the deadlock actually happened before the close, it occurred when a
> flow arrived at the broker at the same time as a message was being sent
> from the broker to a consumer... I'll fix that now on trunk (I don't think
> that looks like a new issue, but we should fix it anyway). The effect of
> the deadlock would be that that queue would no longer be distributing
> messages.
>
> -- Rob
>
>
>>
>>
>> The next planned build is our first RC on March 4th.
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>
>
Re: 0.32 release update - Beta is available
Posted by Rob Godfrey <ro...@gmail.com>.
On 5 March 2015 at 12:42, Gordon Sim <gs...@redhat.com> wrote:
> On 03/05/2015 11:21 AM, Rob Godfrey wrote:
>
>> To verify, I downloaded the broker tgz from here
>> https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-
>> Java-Artefact-Release-0.32/
>> expanded
>> it into an empty directory, set QPID work to a non existent location, and
>> ran bin/qpid-server.
>>
>> On startup the broker had a single (Json) virtual host node, containing an
>> (active) Derby virtual host.
>>
>> This is the behaviour I would expect...
>>
>
> Retested and I can confirm I see the same. Looking at my bash history, it
> seems I got a typo in first setting QPID_WORK, presumably meaning it picked
> up something stale from the default location(?). Apologies for the false
> alarm, it was a user error.
>
>
>
Interesting... I guess it found something where the virtual host
configuration had been blown away... otherwise it should have automatically
upgraded your old config. Anyway, glad to know that the out of the box
installation does have a vhost as expected.
-- Rob
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: 0.32 release update - Beta is available
Posted by Robbie Gemmell <ro...@gmail.com>.
On 5 March 2015 at 11:42, Gordon Sim <gs...@redhat.com> wrote:
> On 03/05/2015 11:21 AM, Rob Godfrey wrote:
>>
>> To verify, I downloaded the broker tgz from here
>>
>> https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Artefact-Release-0.32/
>> expanded
>> it into an empty directory, set QPID work to a non existent location, and
>> ran bin/qpid-server.
>>
>> On startup the broker had a single (Json) virtual host node, containing an
>> (active) Derby virtual host.
>>
>> This is the behaviour I would expect...
>
>
> Retested and I can confirm I see the same. Looking at my bash history, it
> seems I got a typo in first setting QPID_WORK, presumably meaning it picked
> up something stale from the default location(?).
It defaults to your homedir.
> Apologies for the false
> alarm, it was a user error.
>
Possibly the stale config could have been rejected, depending on
whether what is no longer current in it makes it illegal or just not
complete.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: 0.32 release update - Beta is available
Posted by Gordon Sim <gs...@redhat.com>.
On 03/05/2015 11:21 AM, Rob Godfrey wrote:
> To verify, I downloaded the broker tgz from here
> https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Artefact-Release-0.32/
> expanded
> it into an empty directory, set QPID work to a non existent location, and
> ran bin/qpid-server.
>
> On startup the broker had a single (Json) virtual host node, containing an
> (active) Derby virtual host.
>
> This is the behaviour I would expect...
Retested and I can confirm I see the same. Looking at my bash history,
it seems I got a typo in first setting QPID_WORK, presumably meaning it
picked up something stale from the default location(?). Apologies for
the false alarm, it was a user error.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: 0.32 release update - Beta is available
Posted by Rob Godfrey <ro...@gmail.com>.
To verify, I downloaded the broker tgz from here
https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Artefact-Release-0.32/
expanded
it into an empty directory, set QPID work to a non existent location, and
ran bin/qpid-server.
On startup the broker had a single (Json) virtual host node, containing an
(active) Derby virtual host.
This is the behaviour I would expect...
-- Rob
On 5 March 2015 at 11:07, Rob Godfrey <ro...@gmail.com> wrote:
>
>
> On 5 March 2015 at 10:55, Gordon Sim <gs...@redhat.com> wrote:
>
>> On 03/04/2015 09:38 PM, Rob Godfrey wrote:
>>
>>> That's odd... The out of the box config should have a virtualhost. Were
>>> you running a completely fresh install, or were you running with an
>>> existing config/work directory?
>>>
>>
>> It was a completely fresh install and I set QPID_WORK to the new install
>> directory. Perhaps that wasn't correct anymore?
>>
>>
> Can you give the exact steps you used to install / start... The broker
> starts up with an initial config which has a parameterized initial virtual
> host. I admit I normally just start from within my IDE, so I may be doing
> something different somehow. If you could also provide the config json
> file that the broker writes on first startup (indeed a tar of the whole
> work directory) prior to you adding a virtual host that would be very
> useful.
>
>
>> The management console showed no virtual hosts, theough the 'default' for
>> the broker was still listed as 'default' in the broker section above this.
>> I create a virtual host named default and everything worked. (Whats a
>> virtual host node btw? I seem to need to create one of those along side my
>> virtual host?)
>>
>>
> The VirtualHostNode was something we added to support HA replication...
> The VirtualHostNode represents the Broker's knowledge of the Virtual Host
> (i.e. enough configuration to go find the virtual host and its
> configuration), for a non HA virtual host that might be something like the
> type of configuration store (JSON, Derby, BDB, etc) and a path. For the
> BDB HA virtual host node it includes the connection information so the
> virtual host node can join the replication group. Where a different broker
> is currently the master for a virtual host, the virtual host node will not
> have an active virtual host underneath it, but will show the state of the
> other nodes in the group (which are on other brokers) so you can see where
> the master is currently residing.
>
>
>> In terms of authentication, by default PLAIN is no longer enabled over
>>> non-TLS connections.
>>>
>>
>> I can see the logic. The python 0-10 client by default (i.e. without the
>> cyrus sasl integration installed) only has ANONYMOUS and PLAIN, so was
>> unable to connect. Next time I'll try ssl.
>>
>>
> Yes - my thinking is really that the default install of the broker should
> either add ANONYMOUS support, or we should have some sort of initial
> configuration questionnaire to guide people through the first run of the
> broker. Having an initial password file with "guest", "guest" in it is
> just a horrible thing to do.
>
>
>> There *seems* to be something odd happening when trying to consume
>>>> messages from a queue. Over 0-10 I only get the messages if I issue a
>>>> message-flush. Over 1.0 I sometimes can't get any messages out at all.
>>>> Not
>>>> sure if this is only when queue was created over 0-10. Even for a queue
>>>> created through management, I was not getting messages at times after
>>>> having sent them and had them accepted (switching back to 0-10 and
>>>> flushing, I could see them all as expected). If the receiver is active
>>>> before messages are sent (whether through exchanges or direct through
>>>> queues), receiving seems to work ok.
>>>>
>>>> Got a deadlock trying to stop the (java) broker, see attached. On
>>>> restarting, my virtual host was there but somehow things were corrupted
>>>> and
>>>> could not connect again until I deleted and recreated it.
>>>>
>>>
>>>
>>> So, the deadlock actually happened before the close, it occurred when a
>>> flow arrived at the broker at the same time as a message was being sent
>>> from the broker to a consumer... I'll fix that now on trunk (I don't
>>> think
>>> that looks like a new issue, but we should fix it anyway). The effect of
>>> the deadlock would be that that queue would no longer be distributing
>>> messages.
>>>
>>
>> I only noticed the deadlock when trying to stop the broker - it just
>> hangs. I can see on my current process I have two deadlocks (before
>> shutting down). Probably the same ones, but just in case its of use,
>> another stackdump attached.
>>
>> This does indeed sound like part of the problem at least with the
>> receive. The queue wasn't completely jammed however, as I could get
>> messages by rerunning the receiver over 0-10 without flushing.
>>
>>
> There'll be potential (depending on whether all the messages in the queue
> are acquired) for independent flows to get through... Basically once it's
> deadlocked there's no guarantees as to how the thing will behave, so I'm
> not going to try to reason about the message sending stuff until/unless we
> can replicate it with the deadlock fixed.
>
> -- Rob
>
>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>
>
Re: 0.32 release update - Beta is available
Posted by Rob Godfrey <ro...@gmail.com>.
On 5 March 2015 at 10:55, Gordon Sim <gs...@redhat.com> wrote:
> On 03/04/2015 09:38 PM, Rob Godfrey wrote:
>
>> That's odd... The out of the box config should have a virtualhost. Were
>> you running a completely fresh install, or were you running with an
>> existing config/work directory?
>>
>
> It was a completely fresh install and I set QPID_WORK to the new install
> directory. Perhaps that wasn't correct anymore?
>
>
Can you give the exact steps you used to install / start... The broker
starts up with an initial config which has a parameterized initial virtual
host. I admit I normally just start from within my IDE, so I may be doing
something different somehow. If you could also provide the config json
file that the broker writes on first startup (indeed a tar of the whole
work directory) prior to you adding a virtual host that would be very
useful.
> The management console showed no virtual hosts, theough the 'default' for
> the broker was still listed as 'default' in the broker section above this.
> I create a virtual host named default and everything worked. (Whats a
> virtual host node btw? I seem to need to create one of those along side my
> virtual host?)
>
>
The VirtualHostNode was something we added to support HA replication... The
VirtualHostNode represents the Broker's knowledge of the Virtual Host (i.e.
enough configuration to go find the virtual host and its configuration),
for a non HA virtual host that might be something like the type of
configuration store (JSON, Derby, BDB, etc) and a path. For the BDB HA
virtual host node it includes the connection information so the virtual
host node can join the replication group. Where a different broker is
currently the master for a virtual host, the virtual host node will not
have an active virtual host underneath it, but will show the state of the
other nodes in the group (which are on other brokers) so you can see where
the master is currently residing.
> In terms of authentication, by default PLAIN is no longer enabled over
>> non-TLS connections.
>>
>
> I can see the logic. The python 0-10 client by default (i.e. without the
> cyrus sasl integration installed) only has ANONYMOUS and PLAIN, so was
> unable to connect. Next time I'll try ssl.
>
>
Yes - my thinking is really that the default install of the broker should
either add ANONYMOUS support, or we should have some sort of initial
configuration questionnaire to guide people through the first run of the
broker. Having an initial password file with "guest", "guest" in it is
just a horrible thing to do.
> There *seems* to be something odd happening when trying to consume
>>> messages from a queue. Over 0-10 I only get the messages if I issue a
>>> message-flush. Over 1.0 I sometimes can't get any messages out at all.
>>> Not
>>> sure if this is only when queue was created over 0-10. Even for a queue
>>> created through management, I was not getting messages at times after
>>> having sent them and had them accepted (switching back to 0-10 and
>>> flushing, I could see them all as expected). If the receiver is active
>>> before messages are sent (whether through exchanges or direct through
>>> queues), receiving seems to work ok.
>>>
>>> Got a deadlock trying to stop the (java) broker, see attached. On
>>> restarting, my virtual host was there but somehow things were corrupted
>>> and
>>> could not connect again until I deleted and recreated it.
>>>
>>
>>
>> So, the deadlock actually happened before the close, it occurred when a
>> flow arrived at the broker at the same time as a message was being sent
>> from the broker to a consumer... I'll fix that now on trunk (I don't think
>> that looks like a new issue, but we should fix it anyway). The effect of
>> the deadlock would be that that queue would no longer be distributing
>> messages.
>>
>
> I only noticed the deadlock when trying to stop the broker - it just
> hangs. I can see on my current process I have two deadlocks (before
> shutting down). Probably the same ones, but just in case its of use,
> another stackdump attached.
>
> This does indeed sound like part of the problem at least with the receive.
> The queue wasn't completely jammed however, as I could get messages by
> rerunning the receiver over 0-10 without flushing.
>
>
There'll be potential (depending on whether all the messages in the queue
are acquired) for independent flows to get through... Basically once it's
deadlocked there's no guarantees as to how the thing will behave, so I'm
not going to try to reason about the message sending stuff until/unless we
can replicate it with the deadlock fixed.
-- Rob
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
Re: 0.32 release update - Beta is available
Posted by Gordon Sim <gs...@redhat.com>.
On 03/04/2015 09:38 PM, Rob Godfrey wrote:
> That's odd... The out of the box config should have a virtualhost. Were
> you running a completely fresh install, or were you running with an
> existing config/work directory?
It was a completely fresh install and I set QPID_WORK to the new
install directory. Perhaps that wasn't correct anymore?
The management console showed no virtual hosts, theough the 'default'
for the broker was still listed as 'default' in the broker section above
this. I create a virtual host named default and everything worked.
(Whats a virtual host node btw? I seem to need to create one of those
along side my virtual host?)
> In terms of authentication, by default PLAIN is no longer enabled over
> non-TLS connections.
I can see the logic. The python 0-10 client by default (i.e. without the
cyrus sasl integration installed) only has ANONYMOUS and PLAIN, so was
unable to connect. Next time I'll try ssl.
>> There *seems* to be something odd happening when trying to consume
>> messages from a queue. Over 0-10 I only get the messages if I issue a
>> message-flush. Over 1.0 I sometimes can't get any messages out at all. Not
>> sure if this is only when queue was created over 0-10. Even for a queue
>> created through management, I was not getting messages at times after
>> having sent them and had them accepted (switching back to 0-10 and
>> flushing, I could see them all as expected). If the receiver is active
>> before messages are sent (whether through exchanges or direct through
>> queues), receiving seems to work ok.
>>
>> Got a deadlock trying to stop the (java) broker, see attached. On
>> restarting, my virtual host was there but somehow things were corrupted and
>> could not connect again until I deleted and recreated it.
>
>
> So, the deadlock actually happened before the close, it occurred when a
> flow arrived at the broker at the same time as a message was being sent
> from the broker to a consumer... I'll fix that now on trunk (I don't think
> that looks like a new issue, but we should fix it anyway). The effect of
> the deadlock would be that that queue would no longer be distributing
> messages.
I only noticed the deadlock when trying to stop the broker - it just
hangs. I can see on my current process I have two deadlocks (before
shutting down). Probably the same ones, but just in case its of use,
another stackdump attached.
This does indeed sound like part of the problem at least with the
receive. The queue wasn't completely jammed however, as I could get
messages by rerunning the receiver over 0-10 without flushing.
Re: 0.32 release update - Beta is available
Posted by Rob Godfrey <ro...@gmail.com>.
On 4 March 2015 at 22:02, Gordon Sim <gs...@redhat.com> wrote:
> On 02/20/2015 11:39 AM, Justin Ross wrote:
>
>> Hi, everyone. We have branched for release, and 0.32 beta is now
>> available.
>>
>> Release branch: https://svn.apache.org/repos/asf/qpid/branches/0.32/
>> Release artifacts: https://dist.apache.org/repos/
>> dist/dev/qpid/0.32-beta/
>> Release tool log output:
>> http://people.apache.org/~jross/qpid-0.32-beta.log
>>
>> This is pre-release software, for testing only.
>>
>> Now that we've branched, 0.32 changes require developer review and release
>> manager approval. See the release page for details. It means as well
>> that
>> trunk has opened for forward development.
>>
>> Please test the beta in your environment and report your results on the
>> list. Thank you very much to those who tested the alpha.
>>
>
> Built and installed qpid-cpp (against latest proton master), java broker,
> python client, qmf lib and tools.
>
> Tests and tools ran fine against c++ broker.
>
> Had some issues with the java broker. It now starts with no virtual host
> defined(?). Meaning that any attempt to connect got an error. (This is
> after enabling anonymous, as even plain appeared to be disabled by
> default?). After creating a virtual host, was able to run some tests
> against it using qpid-cpp clients over both 0-10 and 1.0.
>
That's odd... The out of the box config should have a virtualhost. Were
you running a completely fresh install, or were you running with an
existing config/work directory?
In terms of authentication, by default PLAIN is no longer enabled over
non-TLS connections.
>
> There *seems* to be something odd happening when trying to consume
> messages from a queue. Over 0-10 I only get the messages if I issue a
> message-flush. Over 1.0 I sometimes can't get any messages out at all. Not
> sure if this is only when queue was created over 0-10. Even for a queue
> created through management, I was not getting messages at times after
> having sent them and had them accepted (switching back to 0-10 and
> flushing, I could see them all as expected). If the receiver is active
> before messages are sent (whether through exchanges or direct through
> queues), receiving seems to work ok.
>
> Got a deadlock trying to stop the (java) broker, see attached. On
> restarting, my virtual host was there but somehow things were corrupted and
> could not connect again until I deleted and recreated it.
So, the deadlock actually happened before the close, it occurred when a
flow arrived at the broker at the same time as a message was being sent
from the broker to a consumer... I'll fix that now on trunk (I don't think
that looks like a new issue, but we should fix it anyway). The effect of
the deadlock would be that that queue would no longer be distributing
messages.
-- Rob
>
>
> The next planned build is our first RC on March 4th.
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
Re: 0.32 release update - Beta is available
Posted by Gordon Sim <gs...@redhat.com>.
On 02/20/2015 11:39 AM, Justin Ross wrote:
> Hi, everyone. We have branched for release, and 0.32 beta is now available.
>
> Release branch: https://svn.apache.org/repos/asf/qpid/branches/0.32/
> Release artifacts: https://dist.apache.org/repos/dist/dev/qpid/0.32-beta/
> Release tool log output:
> http://people.apache.org/~jross/qpid-0.32-beta.log
>
> This is pre-release software, for testing only.
>
> Now that we've branched, 0.32 changes require developer review and release
> manager approval. See the release page for details. It means as well that
> trunk has opened for forward development.
>
> Please test the beta in your environment and report your results on the
> list. Thank you very much to those who tested the alpha.
Built and installed qpid-cpp (against latest proton master), java
broker, python client, qmf lib and tools.
Tests and tools ran fine against c++ broker.
Had some issues with the java broker. It now starts with no virtual host
defined(?). Meaning that any attempt to connect got an error. (This is
after enabling anonymous, as even plain appeared to be disabled by
default?). After creating a virtual host, was able to run some tests
against it using qpid-cpp clients over both 0-10 and 1.0.
There *seems* to be something odd happening when trying to consume
messages from a queue. Over 0-10 I only get the messages if I issue a
message-flush. Over 1.0 I sometimes can't get any messages out at all.
Not sure if this is only when queue was created over 0-10. Even for a
queue created through management, I was not getting messages at times
after having sent them and had them accepted (switching back to 0-10 and
flushing, I could see them all as expected). If the receiver is active
before messages are sent (whether through exchanges or direct through
queues), receiving seems to work ok.
Got a deadlock trying to stop the (java) broker, see attached. On
restarting, my virtual host was there but somehow things were corrupted
and could not connect again until I deleted and recreated it.
> The next planned build is our first RC on March 4th.
Re: 0.32 release update - Beta is available
Posted by Justin Ross <ju...@gmail.com>.
My testing shows three test failures in the cpp tree. Everything else
passes for me.
https://gist.github.com/ssorj/cfd6b48cda7f37bb665d
The first two failures there are from an unguarded reacharound in the
source tree.
The last is more interesting. In this instance I was building against
0.7. I ran all of these tests on Fedora 20 x86-64.
On Fri, Feb 20, 2015 at 6:39 AM, Justin Ross <ju...@gmail.com> wrote:
> Hi, everyone. We have branched for release, and 0.32 beta is now
> available.
>
> Release branch: https://svn.apache.org/repos/asf/qpid/branches/0.32/
> Release artifacts:
> https://dist.apache.org/repos/dist/dev/qpid/0.32-beta/
> Release tool log output:
> http://people.apache.org/~jross/qpid-0.32-beta.log
>
> This is pre-release software, for testing only.
>
> Now that we've branched, 0.32 changes require developer review and release
> manager approval. See the release page for details. It means as well that
> trunk has opened for forward development.
>
> Please test the beta in your environment and report your results on the
> list. Thank you very much to those who tested the alpha.
>
> The next planned build is our first RC on March 4th.
>
> Thanks!
> Justin
>
> ---
> 0.32 release page:
> https://cwiki.apache.org/confluence/display/qpid/0.32+Release
>
Re: 0.32 release update - Beta is available
Posted by Chuck Rolke <cr...@redhat.com>.
OK running broker and c++ messaging client work on windows Visual Studio 2010, x86, debug
* Running with today's proton master branch
* Runs C++ messaging examples
----- Original Message -----
> From: "Justin Ross" <ju...@gmail.com>
> To: users@qpid.apache.org
> Sent: Friday, February 20, 2015 6:39:24 AM
> Subject: 0.32 release update - Beta is available
>
> Hi, everyone. We have branched for release, and 0.32 beta is now available.
>
> Release branch: https://svn.apache.org/repos/asf/qpid/branches/0.32/
> Release artifacts: https://dist.apache.org/repos/dist/dev/qpid/0.32-beta/
> Release tool log output:
> http://people.apache.org/~jross/qpid-0.32-beta.log
>
> This is pre-release software, for testing only.
>
> Now that we've branched, 0.32 changes require developer review and release
> manager approval. See the release page for details. It means as well that
> trunk has opened for forward development.
>
> Please test the beta in your environment and report your results on the
> list. Thank you very much to those who tested the alpha.
>
> The next planned build is our first RC on March 4th.
>
> Thanks!
> Justin
>
> ---
> 0.32 release page:
> https://cwiki.apache.org/confluence/display/qpid/0.32+Release
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org