[RESULT] [VOTE] Release Apache Qpid CPP 1.37.0

2017-11-24 Thread Robbie Gemmell
There were 5 binding +1 votes, 1 non-binding +1 vote, and no other
votes received. The vote has passed.

I will add the files to the dist release repo and create the final tag
shortly. The website will be updated after the release has had time to
sync to the mirrors.

Robbie

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



Re: Java Broker performance

2017-11-24 Thread Tomas Soltys
Hi Keith,

Please find attached  cpp_vs_java.gz
  . This
archive contains:
* *java* - setup of Java broker (v7.0.0)
* *cpp* - setup of C++ broker (v1.36.0)
* *proton-client* - C++client based on Qpid proton (v0.18.1)
* *java_trace.log* - trace log from client sending 20 messages (10240 Bytes
each) to Java broker
* *java_trace.log* - trace log from client sending 20 messages (10240 Bytes
each) to C++ broker

One thing I've noticed in logs is that C++ broker is sending dispositions in
chunks of 5 whereas Java broker does this for each message separately.

Best regards,
Tomas



--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html

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



Re: Java Broker performance

2017-11-24 Thread Robbie Gemmell
Your earlier mail was clear Tomas, I didn't even know you replied to
me as I don't use the Nabble interface. I just wanted to reiterate it
is also important we know which client(s) and which code any
comparisons are performed with otherwise the numbers simply cant be
reasoned about fully. While different clients might act/perform
similarly in some cases against particular servers, in others cases
they can/will be very different.

The example JMS code you gave earlier is doing a synchronous send of a
persistent message, so if you are running single producer synchronous
sends on a hard disk that can only do say ~100syncs/sec, and getting
vastly faster results in one case, then something is probably awry. In
such a situation, both brokers performance should be gated by the
synchronous sends and need to sync to disk before responding to the
client. Keiths testing suggested that is the case, seeing similar
results for both brokers in his testing.

In the case of a C[++] client doing asynchronous sends then it would
currently be expected for the C++ broker to be significantly faster
based on the details Rob gave, as even if waiting for settlement after
100 messages its still mostly async in comparison. Your example code
didnt do that however, so again seeing what you are actually doing
would be needed to fully reason about it.

You mention Qpid JMS 0.23.0 below, while earlier in the thread you
mentioned 0.27.0 when giving example code. Did you actually change
clients? Did you use the same JMS application code provided in this
thread in both cases? If you did use that example JMS code, I would
actually have to start questioning if the messages are really being
persisted (and synced to disk before response) in both cases if you
are seeing radically different numbers between them.

Following Keith's suggestion would be a good idea.

Robbie

On 24 November 2017 at 10:58, Tomas Soltys  wrote:
> Hi Robbie,
>
> I just realized that I placed my response to incorrect person. It supposed
> to be a reply to Keith's message.
>
> To your questions. The test was performed with C client based on proton
> 0.18.1. However, I got very similar results also with qpid-send tool which
> settles after each message.
>



> I've also tried sending using 0-10 and 1.0 protocol versions but no
> significant differences.
>
> I also executed test client based on Qpid JMS 0.23.0 with very similar
> results. In all cases C++ broker was able to settle and send acknowledgment
> way much faster than java broker.
>
> Is there something in the settings that can be tweaked to improve IO
> performance?
>
> Regards,
> Tomas
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>

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



Re: Java Broker performance

2017-11-24 Thread Keith W
Hi Tomas,

Can I suggest that you share the logs from both brokers for the two
amq_send.sh test?   Also separately, I suggest a run of amq_send.sh
with a small number of message, say message-count 20, with Proton
trace logging enabled (export PN_TRACE_FRM=true) on the client side.
Repeat this with both Brokers and share.

With regard to Broker-J performance, we know that BDB will outperform
Derby for many use-cases.  The BDB plugin has received much more
tuning over the years than Derby.  I know you have already said you
tested with both earlier in the thread, but I wanted to point it out.

cheers Keith



On 24 November 2017 at 10:58, Tomas Soltys  wrote:
> Hi Robbie,
>
> I just realized that I placed my response to incorrect person. It supposed
> to be a reply to Keith's message.
>
> To your questions. The test was performed with C client based on proton
> 0.18.1. However, I got very similar results also with qpid-send tool which
> settles after each message.
>
> I've also tried sending using 0-10 and 1.0 protocol versions but no
> significant differences.
>
> I also executed test client based on Qpid JMS 0.23.0 with very similar
> results. In all cases C++ broker was able to settle and send acknowledgment
> way much faster than java broker.
>
> Is there something in the settings that can be tweaked to improve IO
> performance?
>
> Regards,
> Tomas
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>

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



Re: Java Broker performance

2017-11-24 Thread Tomas Soltys
Hi Robbie,

I just realized that I placed my response to incorrect person. It supposed
to be a reply to Keith's message.

To your questions. The test was performed with C client based on proton
0.18.1. However, I got very similar results also with qpid-send tool which
settles after each message.

I've also tried sending using 0-10 and 1.0 protocol versions but no
significant differences.

I also executed test client based on Qpid JMS 0.23.0 with very similar
results. In all cases C++ broker was able to settle and send acknowledgment
way much faster than java broker.

Is there something in the settings that can be tweaked to improve IO
performance?

Regards,
Tomas



--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html

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



[ANNOUNCE] Apache Qpid for Java 6.1.5 released

2017-11-24 Thread Oleksandr Rudyy
The Apache Qpid (https://qpid.apache.org) community is pleased to announce
the immediate availability of Apache Qpid for Java 6.1.5.

This release addresses defects and enhancements in Qpid Broker-J
(previously known as Qpid Broker for Java).

The release is available now from our website:
https://qpid.apache.org/releases/qpid-java-6.1.5/index.html

Binaries are also available via Maven Central:
https://qpid.apache.org/maven.html

Release notes can be found at:
https://qpid.apache.org/releases/qpid-java-6.1.5/release-notes.html


Thanks to all involved,
Alex

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