CVE-2018-17187: Apache Qpid Proton-J transport TLS wrapper hostname
verification mode not implemented
Severity: Important
Vendor: The Apache Software Foundation
Versions Affected: Versions 0.3 to 0.29.0
Description:
The Proton-J transport includes an optional wrapper layer to perform TLS,
Hello,
I'm using 1 dispatch-router (1.3.0), 2 brokers (7.0.3) and a simple topic/queue
configuration.
I was testing the multicast distribution on the dispatch-router with 1 producer
on the topic and 2 listeners on the queue.
In AUTO_ACK everything seems to work fine but when I switch to
On 12/11/18 13:07, VERMEULEN Olivier wrote:
Hello,
I'm using 1 dispatch-router (1.3.0), 2 brokers (7.0.3) and a simple topic/queue
configuration.
I was testing the multicast distribution on the dispatch-router with 1 producer
on the topic and 2 listeners on the queue.
In AUTO_ACK everything
On 12/11/18 14:58, VERMEULEN Olivier wrote:
address {
prefix: queue_1
waypoint: yes
distribution: multicast
}
This will not give you end to end acknowledgement with consuming
clients. The router will acknowledge each message received by the queue
on receipt, causing the
Would it also work if the queue is sharded across multiple brokers?
Will my consumers receive the messages stored in all the brokers for a given
queue?
-Original Message-
From: Gordon Sim
Sent: lundi 12 novembre 2018 16:09
To: users@qpid.apache.org
Subject: Re: [Dispatch Router]
On 12/11/18 15:50, VERMEULEN Olivier wrote:
Would it also work if the queue is sharded across multiple brokers?
Will my consumers receive the messages stored in all the brokers for a given
queue?
No, each link would be routed to one broker.
I tried to reduce the test case as much as possible.
I'm sending a message with the following code:
Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
Destination destination = session.createTopic("topic_1");
MessageProducer producer =
On Mon, 12 Nov 2018 at 18:43, Robbie Gemmell wrote:
>
> Hi folks,
>
> I have put together a spin for a 0.38.0 Qpid JMS client release,
> please give it a test out and vote accordingly.
>
> The source and binary archives can be grabbed from:
>
The Apache Qpid (http://qpid.apache.org) community is pleased to announce
the immediate availability of Apache Qpid Proton-J 0.30.0.
Apache Qpid Proton-J is a messaging library for the Advanced Message Queuing
Protocol 1.0 (AMQP 1.0, ISO/IEC 19464, http://www.amqp.org). It can be used
in a wide
Hi folks,
I have put together a spin for a 0.38.0 Qpid JMS client release,
please give it a test out and vote accordingly.
The source and binary archives can be grabbed from:
https://dist.apache.org/repos/dist/dev/qpid/jms/0.38.0-rc1/
The maven artifacts are also staged for now at:
when all receivers acknowledge it
-Original Message-
From: Gordon Sim
Sent: lundi 12 novembre 2018 17:38
To: users@qpid.apache.org
Subject: Re: [Dispatch Router] multicast distribution
On 12/11/18 16:35, VERMEULEN Olivier wrote:
> So this use case (client acknowledged multicast with
So this use case (client acknowledged multicast with message routing) will
never be supported ?
-Original Message-
From: Gordon Sim
Sent: lundi 12 novembre 2018 17:20
To: users@qpid.apache.org
Subject: Re: [Dispatch Router] multicast distribution
On 12/11/18 15:50, VERMEULEN Olivier
Kim,
Thanks for clearing that up for me, does it support SAN storage blocks.
Where can i read more about linearstore if i want to know the low level
internals?
Ram
On Mon, Nov 12, 2018 at 8:32 AM Kim van der Riet
wrote:
> The linearstore relies on using libaio for its async disk writes. The
>
Hi All,
I'm working on migrating a python2 app to python3, which also means
transitioning to Proton. The application is communicating with a c++ qpid
broker.
*One of the last roadblocks I'm having in this transition is figuring out
how to dynamically generate a queue with bindings hooked up.*
On 12/11/18 20:07, gsupa wrote:
Hi All,
I'm working on migrating a python2 app to python3, which also means
transitioning to Proton. The application is communicating with a c++ qpid
broker.
*One of the last roadblocks I'm having in this transition is figuring out
how to dynamically generate a
On 12/11/18 19:32, VERMEULEN Olivier wrote:
when all receivers acknowledge it
How is the set of 'all' receivers defined? All those active at the time
the message is received by the first router? (What if one of them had
been disconnected just before that message?)
If a message is not
The linearstore relies on using libaio for its async disk writes. The
O_DIRECT flag is used, and this requires a block of aligned memory to
serve as a memory buffer for disk write operations. To my knowledge,
this technique only works with local disks and controllers. NFS does not
allow for
On 12/11/18 16:35, VERMEULEN Olivier wrote:
So this use case (client acknowledged multicast with message routing) will
never be supported ?
What is you intention? That the message be dequeued when any receiver
acknowledges it? Or only when all receivers acknowledge it? Or that each
receiver
18 matches
Mail list logo
