+1 ... I used the RC1 to build Qpid C++ broker and run my AMQP 1.0 tests
against it. All seems to be OK.
On Fri, Feb 3, 2017 at 6:35 PM, Robbie Gemmell
wrote:
> Hi folks,
>
> I have put together a first spin for a 0.17.0 Qpid Proton release,
> please test it and vote accordingly.
>
> Note that P
On 6 February 2017 at 19:03, Robbie Gemmell
wrote:
> On 6 February 2017 at 17:50, Rob Godfrey wrote:
> > On 6 February 2017 at 18:44, Ted Ross wrote:
> >
> >> It seems odd that the client creates a _sender_ to the temporary queue
> >> that it will never send messages _to_ but will receive messa
On 6 February 2017 at 17:50, Rob Godfrey wrote:
> On 6 February 2017 at 18:44, Ted Ross wrote:
>
>> It seems odd that the client creates a _sender_ to the temporary queue
>> that it will never send messages _to_ but will receive messages _from_.
>>
>>
> This is because JMS semantics require the t
On 02/06/2017 12:50 PM, Rob Godfrey wrote:
On 6 February 2017 at 18:44, Ted Ross wrote:
It seems odd that the client creates a _sender_ to the temporary queue
that it will never send messages _to_ but will receive messages _from_.
This is because JMS semantics require the temporary node t
On 6 February 2017 at 17:44, Ted Ross wrote:
> It seems odd that the client creates a _sender_ to the temporary queue that
> it will never send messages _to_ but will receive messages _from_.
>
It does this because it would never receive messages on this link
either, and it seemed less confusing
On 6 February 2017 at 18:44, Ted Ross wrote:
> It seems odd that the client creates a _sender_ to the temporary queue
> that it will never send messages _to_ but will receive messages _from_.
>
>
This is because JMS semantics require the temporary node to have a lifetime
scoped to the session (no
It seems odd that the client creates a _sender_ to the temporary queue
that it will never send messages _to_ but will receive messages _from_.
Anyway, when the client creates a receiver with a dynamic source (and no
dynamic-node-properties), the router will accept the link and assign a
tempora
+1
Tested:
pyngus unit tests (py27 & py35) - fedora 24
oslo.messaging unit and functional (py27 & py35) - fedora 24
rsyslog plugin - centos7 docker image
-K
- Original Message -
> From: "Robbie Gemmell"
> To: users@qpid.apache.org
> Sent: Friday, February 3, 2017 12:35:47 PM
>
On 3 February 2017 at 17:35, Robbie Gemmell wrote:
> Hi folks,
>
> I have put together a first spin for a 0.17.0 Qpid Proton release,
> please test it and vote accordingly.
>
> Note that Proton-J is now independently released, its vote is also under way.
>
> The source archive can be grabbed from:
Symbolic +1
Compiled Proton + unit tests on Linux (GCC 4.9.1)
Compiled Proton + unit tests on Windows (Visual Studio 2013)
Compiled Proton + unit tests on Solaris x86 (SunStudio 12.1)
Compiled Proton + unit tests on Solaris Sparc (SunStudio 12.1)
Compiled Qpid Dispatch 0.7.0 + unit tests (Wit
As an aside, for anyone else wanting to do this type of thing, I used
this to add a remote called 'github' to my existing checkout and make
the PRs available at ref github/pr/:
git remote add github https://github.com/apache/qpid-java.git
git config --local --add remote.github.fetch
'+refs/pull/*/
In terms of transactional retirement, the "issue" you highlight only
applies to links for which we expect the broker to hold on to ... which, in
the case of the JMS client, is durable subscriptions only. Moreover, since
the client anyway cannot deal with restoring unsettled state, the client
doesn
FYI if you're testing the RC1 python bindings:
I've built and uploaded pip packages from the 0.17.0rc1 tar file.
To install:
pip install --pre -vvv --no-cache -i https://testpypi.python.org/pypi
python-qpid-proton
-K
- Original Message -
> From: "Robbie Gemmell"
> To: users@qpid.apac
Transactional acquisition is actually quite awkward, I'm not aware of
any client that uses it. Proton can't even support it currently I
believe.
You need to know the transaction id before you flow any credit for it,
which adds extra round trips. When you then discharge the transaction,
any outstan
Hi,
I would like to ask why "transactional retirement" is used by jms
client instead of "transactional acquisition"?
I am sorry if I missed any previous discussion about implementation of
amqp transactions with JMS client. From my point of view the
'transactional acquisition' model would fit bette
- Original Message -
> From: "Robbie Gemmell"
> To: users@qpid.apache.org
> Sent: Monday, February 6, 2017 8:10:21 AM
> Subject: Re: [VOTE] Release Qpid Proton 0.17.0
>
> Thanks for the report Ganesh. I don't see that issue, and I doubt
> other committers have or I expect it would have
Thanks for the report Ganesh. I don't see that issue, and I doubt
other committers have or I expect it would have been noted earlier,
suggesting something different about your environment, which it would
be good to figure out. Is it just that you have emscripten installed
for example?
That it also
On 3 February 2017 at 17:03, Robbie Gemmell wrote:
> Hi folks,
>
> I have put together a first spin for a 0.17.0 Qpid Proton-J release, please
> test it and vote accordingly.
>
> The source and binary archives can be grabbed from:
> https://dist.apache.org/repos/dist/dev/qpid/proton-j/0.17.0-rc1/
If you wanted to get really fancy... for the Java Broker, one possibility
is to write a virtual host implementation which pulls its config from
something like zookeeper... and have the host push changes to zookeeper /
and some sort of mechanism by which changes made to the zookeeper master
are noti
Hello,
These are exactly the type of questions we had when I initiated the thread.
I was actually wondering if there were any solution for the management of a
distributed network of amqp components.
In case of lack of sources of inspiration we had an idea to store the
"target" state in HA store a
Many thanks.
I successfully managed to generate SCRAM-SHA256 password by using code from
AbstractScramAuthenticationManager.java.
Vavricka
--
View this message in context:
http://qpid.2158936.n2.nabble.com/Qpid-Java-Broker-Generate-SHA-256-password-tp7658669p7658778.html
Sent from the Apache
While this does seem like an application concern... I think rolling back
probably makes sense. More generally how are you planning on dealing with
inconsistent state between brokers? What if one of the instances is
temporarily off-line when a new queue is created... or what if you want to
add a n
22 matches
Mail list logo
