date:20191120

Re: [Broker-J] REST-API: how to determine consumer for acquired messages

2019-11-20 Thread Timo Naroska

Yes, I think that would solve the issue. With that ID I can then co-relate with 
the consumer objects returned by the getConsumers REST API.

I see that the bug was moved to 8.0.0 release. It seems like a minor change 
though.
Any chance it can be merged into the next dot release?

Thanks,
Timo

 
On 11/20/19, 1:43 AM, "Rob Godfrey"  wrote:

So I've pushed a change that will return the consumerId of the acquiring
consumer - so for an acquired message you'd additionally something like:

"deliveredToConsumerId" : "406c1d71-1189-41bf-a945-6d21f5fd0753"

Does that meet your requirements?

Thanks,
Rob

On Wed, 6 Nov 2019 at 01:54, Timo Naroska 
wrote:

> https://issues.apache.org/jira/browse/QPID-8373
>
> Thanks,
> Timo
>
> On 11/5/19, 3:53 PM, "Oleksandr Rudyy"  wrote:
>
> Hi Timo,
>
> I think that the reason behind providing consumerNumber in
> 'deliveredTo'
> field was to allow to find the consumer in operational logs.The
> consumer
> number is reported in operational logs due to historical reasons.
> I agree that it make more sense for this REST operation to provide the
> consumer id in  'deliveredTo' field.
> Please raise a JIRA to request the change.
>
> Kind regards,
> Alex
>
> On Tue, 5 Nov 2019 at 23:13, Timo Naroska 
> wrote:
>
> > Hi,
> >
> > for monitoring purposes we're looking for a way to retrieve the
> current
> > messages from a queue and which consumer, if any, is currently
> processing
> > them.
> >
> > I found the getMessageInfo operation on Queue objects which
> enumerates
> > messages. I can determine messages that are currently processed by
> > filtering for state 'Acquired'. However, I don't see a way to
> determine
> > which specific consumer has acquired which messages.
> > There is a 'deliveredTo' field, but the value is some internal
> > _consumerNumber attribute of the consumer that seems to be used
> nowhere
> > else in the REST API.
> >
> > Would it be possible to return the actual consumer ID in the
> deliveredTo
> > field to make it more useful?
> > Another option would be to add the _consumerNumber to the result of
> the
> > Queue getConsumers operation. That would allow cross reference.
> >
> > Any other suggestion? Again I'm looking for a way to determine the
> > consumer that has currently acquired a message from the queue.
> >
> > Thanks
> > Timo
> >
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: Restrict TLS Versions and Ciphers using qpid proton-cpp API

2019-11-20 Thread Justin Ross

I also took a look, and I don't think we have accessors for these in C++.
I raised a ticket for it:

https://issues.apache.org/jira/browse/PROTON-2139



On Thu, Oct 24, 2019 at 7:21 AM Gordon Sim  wrote:

> On 18/10/2019 3:11 pm, bajanfella wrote:
> > I see that there is a pn_ssl_domain_set_protocol and
> > pn_ssl_domain_set_ciphers in the proton-c API. There there equivalent
> > functionality using the C++ API? How do I get access to the
> pn_ssl_domain_t
> > struct from my CPP API?
>
> If not an expert on the proton c++ API, but I don't see a way to do
> either of these things. Justin, Andrew, am I missing some way of doing so?
>

Re: [Qpid-proton-cpp] Performance regression found in 0.29.0

2019-11-20 Thread Rabih M

Hi,

Jira issue created: PROTON-2137
.

Best regards,
Rabih

On Wed, Nov 20, 2019 at 5:01 PM Andrew Stitcher 
wrote:

> Please raise a JIRA with all this information and the reproducer - it
> is very hard to track fixes without this.
>
> Also you could attach your patch, but it is easier in this case to use
> a github PR with a reference to the JIRA. The Apache automation will
> tie them together and this makes it again easier to track.
>
> Andrew
>
> On Tue, 2019-11-19 at 18:04 +, HADI Ali wrote:
> > Hello,
> >
> > After analysis we discovered that the regression is coming from
> > PROTON-2075<
> >
> https://github.com/apache/qpid-proton/commit/e152190459cd75792002d2aae72d351dc22abe27
> >
> > ;: [C++] Allow TLS to use system default trusted certificate.
> > In fact we noticed that the ssl_client_options and the
> > ssl_server_options are not default constructed the same way and that
> > the second one<
> >
> https://github.com/apache/qpid-proton/blob/e152190459cd75792002d2aae72d351dc22abe27/cpp/src/ssl_options.cpp#L99
> > > is calling pni_init_ssl_domain<
> >
> https://github.com/apache/qpid-proton/blob/9dd013335de0694bc52848897b17190f297450c1/c/src/ssl/openssl.c#L475
> > > which is taking some time.
> >
> > What we would like is to avoid initializing ssl when it’s disabled
> > from the connection_options.
> > Does it sound reasonable for you? Should we create a Jira issue and
> > propose a fix?
> >
> > Thanks,
> > Ali & Rabih
> >
> > From: Rabih M 
> > Sent: mercredi 13 novembre 2019 19:22
> > To: users@qpid.apache.org
> > Subject: [Qpid-proton-cpp] Performance regression found in 0.29.0
> >
> > Hello,
> >
> > We are upgrading in our code the proton version from 0.27.0 to
> > 0.29.0.
> > While running our unit tests, we found a considerable performance
> > regression.
> >
> > We were able to reproduce the regression in a very simple use case.
> > Please find the code attached.
> >
> > This test takes 1 ms in the version 0.27.0 and 0.28.0 but it takes 73
> > ms in 0.29.0 .
> >
> > Do you know what might be the cause?
> > We will try to investigate in parallel from our side, too.
> >
> > Thanks,
> > Rabih & Ali
> > ***
> > This e-mail contains information for the intended recipient only. It
> > may contain proprietary material or confidential information. If you
> > are not the intended recipient you are not authorized to distribute,
> > copy or use this e-mail or any attachment to it. Murex cannot
> > guarantee that it is virus free and accepts no responsibility for any
> > loss or damage arising from its use. If you have received this e-mail
> > in error please notify immediately the sender and delete the original
> > email received, any attachments and all copies from your system.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: [Qpid-proton-cpp] Performance regression found in 0.29.0

2019-11-20 Thread Andrew Stitcher

Please raise a JIRA with all this information and the reproducer - it
is very hard to track fixes without this.

Also you could attach your patch, but it is easier in this case to use
a github PR with a reference to the JIRA. The Apache automation will
tie them together and this makes it again easier to track.

Andrew

On Tue, 2019-11-19 at 18:04 +, HADI Ali wrote:
> Hello,
> 
> After analysis we discovered that the regression is coming from
> PROTON-2075<
> https://github.com/apache/qpid-proton/commit/e152190459cd75792002d2aae72d351dc22abe27>
> ;: [C++] Allow TLS to use system default trusted certificate.
> In fact we noticed that the ssl_client_options and the
> ssl_server_options are not default constructed the same way and that
> the second one<
> https://github.com/apache/qpid-proton/blob/e152190459cd75792002d2aae72d351dc22abe27/cpp/src/ssl_options.cpp#L99
> > is calling pni_init_ssl_domain<
> https://github.com/apache/qpid-proton/blob/9dd013335de0694bc52848897b17190f297450c1/c/src/ssl/openssl.c#L475
> > which is taking some time.
> 
> What we would like is to avoid initializing ssl when it’s disabled
> from the connection_options.
> Does it sound reasonable for you? Should we create a Jira issue and
> propose a fix?
> 
> Thanks,
> Ali & Rabih
> 
> From: Rabih M 
> Sent: mercredi 13 novembre 2019 19:22
> To: users@qpid.apache.org
> Subject: [Qpid-proton-cpp] Performance regression found in 0.29.0
> 
> Hello,
> 
> We are upgrading in our code the proton version from 0.27.0 to
> 0.29.0.
> While running our unit tests, we found a considerable performance
> regression.
> 
> We were able to reproduce the regression in a very simple use case.
> Please find the code attached.
> 
> This test takes 1 ms in the version 0.27.0 and 0.28.0 but it takes 73
> ms in 0.29.0 .
> 
> Do you know what might be the cause?
> We will try to investigate in parallel from our side, too.
> 
> Thanks,
> Rabih & Ali
> ***
> This e-mail contains information for the intended recipient only. It
> may contain proprietary material or confidential information. If you
> are not the intended recipient you are not authorized to distribute,
> copy or use this e-mail or any attachment to it. Murex cannot
> guarantee that it is virus free and accepts no responsibility for any
> loss or damage arising from its use. If you have received this e-mail 
> in error please notify immediately the sender and delete the original
> email received, any attachments and all copies from your system.


-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Qpid as a RabbitMQ broker for Java app integration tests - exchange declare arguments

2019-11-20 Thread Lukasz Guzik

Hi Alex,

Yes, currently there's no rush on my side, as I've found some workaround
for the tests.

Thanks,


pon., 18 lis 2019 o 15:16 Oleksandr Rudyy  napisał(a):

> Rob,
>
> I do not have any tentative date for the release yet.
> Potentially, the changes can be ported into 7.1.6 and released as part of
> 7.1.x line.
>
> I have a couple of defects to fix there (I am in process of raising
> corresponding JIRAs). The defects are straight-forward to fix.
>
> Potentially, the version 7.1.6 can released by the end of November.
>
> Łukasz,
> Does end of November work for you?
>
> Kind Regards,
> Alex
>
>
> On Mon, 18 Nov 2019 at 13:23, Rob Godfrey  wrote:
>
>>
>>
>> On Mon, 18 Nov 2019 at 13:42, Lukasz Guzik 
>> wrote:
>>
>>> Hi Rob,
>>>
>>> Yes, this is a perfect solution for me, thank you! :)
>>> Could you please let me know when it will be released?
>>>
>>>
>> Alex - do we have a plan for the next release yet?
>>
>> -- Rob
>>
>>
>>> niedz., 17 lis 2019 o 23:30 Rob Godfrey 
>>> napisał(a):
>>>
 Hi Łukasz,

 I have made an enhancement to the Broker as QPID-8377
  along the lines I
 suggested in my previous mail.  I hope this will meet your requirements.

 Thanks,
 Rob

 On Mon, 11 Nov 2019 at 09:33, Rob Godfrey 
 wrote:

> Hi Łukasz,
>
> firstly let me apologise for not getting back to you sooner.
>
> Secondly, unfortunately I agree that there is no current way to
> explicitly tell the broker to ignore unknown exchange declare arguments,
> and that adding this ability is a good idea.  The simplest approach is
> probably to add a configurable property to the VirtualHost for
> "unknownExchangeDeclareArgumentPolicy" (or something like that) with
> options of FAIL, LOG and IGNORE (where the current behaviour - FAIL - 
> would
> be the default).  If that seems reasonable to you we can raise a JIRA and
> make a change.
>
> Thanks,
> Rob
>
> On Mon, 4 Nov 2019 at 13:31, Lukasz Guzik 
> wrote:
>
>> Hello,
>>
>> I'm working on using Qpid broker as an in-memory AMQP message broker,
>> that
>> will be used in place of RabbitMQ for integration tests of my Java
>> service.
>> While I managed to successfully run Qpid, I'm having issues with my
>> RabbitMQ connector library using some RMQ-specific exchange declare
>> arguments. Basically, Qpid refuses to create an exchange with error:
>> Unsupported exchange declare arguments: x-ha-policy,ha-mode.
>> Is there any option to make Qpid ignore these arguments, or to write a
>> custom handler for these (that will basically do nothing)? I wasn't
>> able to
>> find any solution in the docs nor over the internet, unfortunately.
>>
>> Thank you!
>>
>> --
>>
>> Łukasz Guzik
>>
>> Senior Software Engineer
>>
>> lukasz.gu...@beekeeper.io
>>
>> Beekeeper · beekeeper.io · We are hiring
>> 
>>
>> Beekeeper AG, Pawia 9, 31-154 Cracow, Poland
>>
>> https://www.beekeeper.io/en/company/jobs
>>
>
>>>
>>> --
>>>
>>> Łukasz Guzik
>>>
>>> Senior Software Engineer
>>>
>>> lukasz.gu...@beekeeper.io
>>>
>>> Beekeeper · beekeeper.io · We are hiring
>>> 
>>>
>>> Beekeeper AG, Pawia 9, 31-154 Cracow, Poland
>>>
>>> https://www.beekeeper.io/en/company/jobs
>>>
>>

-- 

Łukasz Guzik

Senior Software Engineer

lukasz.gu...@beekeeper.io

Beekeeper · beekeeper.io · We are hiring


Beekeeper AG, Pawia 9, 31-154 Cracow, Poland

https://www.beekeeper.io/en/company/jobs

Re: [Qpid-proton-cpp] Performance regression found in 0.29.0

2019-11-20 Thread Rabih M

Hello again,

Here is a patch that we propose. All unit tests are green on the master.

Can you please @Andrew Stitcher check if this patch is aligned with what
you meant to do in (PROTON-2075) ?

Best regards,
Rabih & Ali

On Tue, Nov 19, 2019 at 7:04 PM HADI Ali  wrote:

> Hello,
>
> After analysis we discovered that the regression is coming from
> PROTON-2075<
> https://github.com/apache/qpid-proton/commit/e152190459cd75792002d2aae72d351dc22abe27>:
> [C++] Allow TLS to use system default trusted certificate.
> In fact we noticed that the ssl_client_options and the ssl_server_options
> are not default constructed the same way and that the second one<
> https://github.com/apache/qpid-proton/blob/e152190459cd75792002d2aae72d351dc22abe27/cpp/src/ssl_options.cpp#L99>
> is calling pni_init_ssl_domain<
> https://github.com/apache/qpid-proton/blob/9dd013335de0694bc52848897b17190f297450c1/c/src/ssl/openssl.c#L475>
> which is taking some time.
>
> What we would like is to avoid initializing ssl when it’s disabled from
> the connection_options.
> Does it sound reasonable for you? Should we create a Jira issue and
> propose a fix?
>
> Thanks,
> Ali & Rabih
>
> From: Rabih M 
> Sent: mercredi 13 novembre 2019 19:22
> To: users@qpid.apache.org
> Subject: [Qpid-proton-cpp] Performance regression found in 0.29.0
>
> Hello,
>
> We are upgrading in our code the proton version from 0.27.0 to 0.29.0.
> While running our unit tests, we found a considerable performance
> regression.
>
> We were able to reproduce the regression in a very simple use case.
> Please find the code attached.
>
> This test takes 1 ms in the version 0.27.0 and 0.28.0 but it takes 73 ms
> in 0.29.0 .
>
> Do you know what might be the cause?
> We will try to investigate in parallel from our side, too.
>
> Thanks,
> Rabih & Ali
> ***
> This e-mail contains information for the intended recipient only. It may
> contain proprietary material or confidential information. If you are not
> the intended recipient you are not authorized to distribute, copy or use
> this e-mail or any attachment to it. Murex cannot guarantee that it is
> virus free and accepts no responsibility for any loss or damage arising
> from its use. If you have received this e-mail in error please notify
> immediately the sender and delete the original email received, any
> attachments and all copies from your system.
>
diff --git a/cpp/src/connection_options.cpp b/cpp/src/connection_options.cpp
index 2bf281d1..b61c2c68 100644
--- a/cpp/src/connection_options.cpp
+++ b/cpp/src/connection_options.cpp
@@ -175,7 +175,8 @@ class connection_options::impl {
 }
 } else if (!client && ssl_server_options.set) {
 pn_ssl_t *ssl = pn_ssl(pnt);
-if (pn_ssl_init(ssl, ssl_server_options.value.impl_->pn_domain(), 
NULL)) {
+pn_ssl_domain_t* ssl_domain = ssl_server_options.value.impl_ ? 
ssl_server_options.value.impl_->pn_domain() : NULL;
+if (pn_ssl_init(ssl, ssl_domain, NULL)) {
 throw error(MSG("server SSL/TLS initialization error"));
 }
 }
diff --git a/cpp/src/ssl_options.cpp b/cpp/src/ssl_options.cpp
index bd4d5c17..f74f014e 100644
--- a/cpp/src/ssl_options.cpp
+++ b/cpp/src/ssl_options.cpp
@@ -99,7 +99,7 @@ ssl_server_options::ssl_server_options(
 throw error(MSG("SSL server configuration failure requiring client 
certificates using " << db));
 }
 
-ssl_server_options::ssl_server_options() : impl_(new impl) {}
+ssl_server_options::ssl_server_options() : impl_(0) {}
 
 ssl_client_options::ssl_client_options(const ssl_client_options& x): 
impl_(x.impl_) {
 if (impl_) impl_->incref();

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: [Broker-J] REST-API: how to determine consumer for acquired messages

2019-11-20 Thread Rob Godfrey

So I've pushed a change that will return the consumerId of the acquiring
consumer - so for an acquired message you'd additionally something like:

"deliveredToConsumerId" : "406c1d71-1189-41bf-a945-6d21f5fd0753"

Does that meet your requirements?

Thanks,
Rob

On Wed, 6 Nov 2019 at 01:54, Timo Naroska 
wrote:

> https://issues.apache.org/jira/browse/QPID-8373
>
> Thanks,
> Timo
>
> On 11/5/19, 3:53 PM, "Oleksandr Rudyy"  wrote:
>
> Hi Timo,
>
> I think that the reason behind providing consumerNumber in
> 'deliveredTo'
> field was to allow to find the consumer in operational logs.The
> consumer
> number is reported in operational logs due to historical reasons.
> I agree that it make more sense for this REST operation to provide the
> consumer id in  'deliveredTo' field.
> Please raise a JIRA to request the change.
>
> Kind regards,
> Alex
>
> On Tue, 5 Nov 2019 at 23:13, Timo Naroska 
> wrote:
>
> > Hi,
> >
> > for monitoring purposes we're looking for a way to retrieve the
> current
> > messages from a queue and which consumer, if any, is currently
> processing
> > them.
> >
> > I found the getMessageInfo operation on Queue objects which
> enumerates
> > messages. I can determine messages that are currently processed by
> > filtering for state 'Acquired'. However, I don't see a way to
> determine
> > which specific consumer has acquired which messages.
> > There is a 'deliveredTo' field, but the value is some internal
> > _consumerNumber attribute of the consumer that seems to be used
> nowhere
> > else in the REST API.
> >
> > Would it be possible to return the actual consumer ID in the
> deliveredTo
> > field to make it more useful?
> > Another option would be to add the _consumerNumber to the result of
> the
> > Queue getConsumers operation. That would allow cross reference.
> >
> > Any other suggestion? Again I'm looking for a way to determine the
> > consumer that has currently acquired a message from the queue.
> >
> > Thanks
> > Timo
> >
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

RE: Dispatch-Router statistics and CPU consumption

2019-11-20 Thread VERMEULEN Olivier

Hello Ganesh,

In order to monitor our messaging cluster we're are fetching a few statistics 
every minute on both the brokers and the dispatch-routers.
Today we are missing the CPU consumption and indeed I can't access the machine 
running the dispatch-router directly, I just have access to the AMQP management.

Regards,
Olivier

-Original Message-
From: Ganesh Murthy 
Sent: lundi 18 novembre 2019 14:20
To: users@qpid.apache.org
Subject: Re: Dispatch-Router statistics and CPU consumption

On Mon, Nov 18, 2019 at 3:51 AM VERMEULEN Olivier < 
olivier.vermeu...@murex.com> wrote:

> Hello,
>
> We're using the Dispatch-Router 1.9.0.
> Is there a way, using the AMQP management of the Dispatch-Router, to
> retrieve statistics like the CPU consumption?
>
There are no plans to do this at the moment. Can you please explain why you 
want this feature? Do you not have access to the machine running the router to 
run say Linux commands like top/htop ?
Thanks.

>
> Thanks,
> Olivier
> ***
> This e-mail contains information for the intended recipient only. It
> may contain proprietary material or confidential information. If you
> are not the intended recipient you are not authorized to distribute,
> copy or use this e-mail or any attachment to it. Murex cannot
> guarantee that it is virus free and accepts no responsibility for any
> loss or damage arising from its use. If you have received this e-mail
> in error please notify immediately the sender and delete the original
> email received, any attachments and all copies from your system.
>
***
This e-mail contains information for the intended recipient only. It may 
contain proprietary material or confidential information. If you are not the 
intended recipient you are not authorized to distribute, copy or use this 
e-mail or any attachment to it. Murex cannot guarantee that it is virus free 
and accepts no responsibility for any loss or damage arising from its use. If 
you have received this e-mail in error please notify immediately the sender and 
delete the original email received, any attachments and all copies from your 
system.

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: [Broker-J] REST-API: how to determine consumer for acquired messages

Re: Restrict TLS Versions and Ciphers using qpid proton-cpp API

Re: [Qpid-proton-cpp] Performance regression found in 0.29.0

Re: [Qpid-proton-cpp] Performance regression found in 0.29.0

Re: Qpid as a RabbitMQ broker for Java app integration tests - exchange declare arguments

Re: [Qpid-proton-cpp] Performance regression found in 0.29.0

Re: [Broker-J] REST-API: how to determine consumer for acquired messages

RE: Dispatch-Router statistics and CPU consumption

8 matches

Site Navigation

Mail list logo

Footer information