On Mon, 2017-01-09 at 11:37 -0500, Alan Conway wrote:
> ...
> They're not used often because people tend to be too busy to think
> about struct packing, but they are an important perf tuning tool. It
> can be the difference between a single bool packing into 1 bit at
> bestÂ
> vs 64 at worst. That
On Mon, 2017-01-09 at 16:03 +, Robbie Gemmell wrote:
> The 'proton-c' CI job on Jenkins is not happy, and looks to have been
> failing for a while. There may even be more than one issue, with PHP
> bits and Go bits, given the snippets I've c&p below.
>
> https://builds.apache.org/view/M-R/view
They are indeed, those are among the various builds using Proton that
I know have made the switch (though only Artemis has already been
released since then I believe, with 5.15.0 still needing to actually
go out before ActiveMQ 5 completes its transition )
On 9 January 2017 at 22:30, Clebert Sucon
Yep.
Robbie
On 9 January 2017 at 23:28, Jakub Scholz wrote:
> Sounds reasonable to me. I guess that as always ... in case it would be
> needed we can have some patch releases for some critical bugs or security
> issues.
>
> Jakub
>
>
> On Mon, Jan 9, 2017 at 11:28 PM, Robbie Gemmell
> wrote:
>
Sounds reasonable to me. I guess that as always ... in case it would be
needed we can have some patch releases for some critical bugs or security
issues.
Jakub
On Mon, Jan 9, 2017 at 11:28 PM, Robbie Gemmell
wrote:
> I'd like to propose dropping support for Java 7 in the broker and both
> JMS
On 09/01/17 21:27, Gordon Sim wrote:
On 09/01/17 07:52, drasil wrote:
I am sorry, but I have to revoke my previous post. I just realized
that the
working setup is not really working. Without any other changes, the
client
either succeeds or not.
Yes, I confirm I also see occasional failures (le
+1. We have had a similar discussion on ActiveMQ some time ago, and
AFAIK both Artemis and ActiveMQ are Java8+ now.
On Mon, Jan 9, 2017 at 5:28 PM, Robbie Gemmell wrote:
> I'd like to propose dropping support for Java 7 in the broker and both
> JMS clients in their next significant new releases.
I'd like to propose dropping support for Java 7 in the broker and both
JMS clients in their next significant new releases.
Almost a year ago, there was a proposal around preparing to end
support for Java 7 in the broker and AMQP 0-x JMS client, with the the
idea of doing a ~Q3 2016 major release i
On 09/01/17 07:52, drasil wrote:
I am sorry, but I have to revoke my previous post. I just realized that the
working setup is not really working. Without any other changes, the client
either succeeds or not.
Yes, I confirm I also see occasional failures (less frequently than you,
but the frequ
>> Are you expected to leave the client-keys.pem file unencrypted, but readable
>> only by an admin account which runs the qpid-config etc commands,
> Yes, I *think* that is the case at present.
Yes, that works - I should have tested it earlier.
Thanks for the roadmap, I think I'm going to go
On 9 January 2017 at 16:59, Alan Conway wrote:
> On Thu, 2017-01-05 at 08:35 +, Adel Boutros wrote:
>
>> Would it be possible to consider a 0.16.1 release in that case if
>> 0.17.0 is a bit far from being released?
>
> Sounds reasonable to me.
>
I'd personally prefer to avoid doing any 0.16.
My mail went too fast..
Output
---
* Bool case
---> Bool: dummy=1
---> Bool: headReturned = 0
* Int case
---> Int: dummy=1
---> Int: headReturned = 1
From: Adel Boutros
Sent: Monday, January 9, 2017 6:17 PM
To: users@qpid.apache.org
Subject: Re
This bug is actually fixed on SunStudio 12.4. However validating a new compiler
takes some time. So we have to stick with 12.1 for now (We hope to be able to
switch to the newer one in the coming months).
Of course a compiler bug shouldn't be a cause for not using the best practices.
There are
On Mon, 2017-01-09 at 16:51 +, Adel Boutros wrote:
> Hello Alan,
>
>
> I had provided in one of my previous emails in this discussion a
> simple test case which fails. What we noticed is that this failure
> occurs when we have 2 bool fields. It doesn't occur with a single
> bool.
>
> It seem
Hello Alan,
I had provided in one of my previous emails in this discussion a simple test
case which fails. What we noticed is that this failure occurs when we have 2
bool fields. It doesn't occur with a single bool.
It seems that on Solaris with SunStudio 12.1 the wrong byte is changed when
s
On Thu, 2017-01-05 at 08:35 +, Adel Boutros wrote:
> Hello Andrew,
>
>
> Issue reported and patch provided at head of master here: https://iss
> ues.apache.org/jira/browse/PROTON-1382
>
> 2 problems fixed:
>
> * Remove bit fields initialization to fix hanging tests on Solaris
>
> * Add mis
On Wed, 2017-01-04 at 10:39 -0500, Andrew Stitcher wrote:
> On Wed, 2017-01-04 at 14:47 +, Adel Boutros wrote:
> > I found the issue!!
> >
> >
> > It is a Solaris compiler bug:
> >
> > Actually Solaris doesn't handle correctly bit fields in C. This is
> > the case of the struct pn_collector_
The 'proton-c' CI job on Jenkins is not happy, and looks to have been
failing for a while. There may even be more than one issue, with PHP
bits and Go bits, given the snippets I've c&p below.
https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-c/
Can folks with more of a clue about these
On 6 January 2017 at 21:54, Robbie Gemmell wrote:
> On 6 January 2017 at 20:32, Andrew Stitcher wrote:
>> On Fri, 2017-01-06 at 19:28 +, Robbie Gemmell wrote:
>>> On 18 December 2016 at 23:17, Robbie Gemmell >> m> wrote:
>>> > On 16 December 2016 at 18:11, Robbie Gemmell >> > com> wrote:
>>>
Just to cover this part:
*I don't know the code in details but is there a reason for not using a
single connection for the JDBC message store lifecycle?*
Since SQL/JDBC can have at most one open transaction for any given
connection, we would have to have (for AMQP 0-x) one JDBC connection open
pe
Hi Antoine,
I'm not sure I'm totally clear on what you mean by "I cannot lose messages"
in this context. Are you saying that if a consumer is connected, then it
should receive all messages which arrive on the "topic" from the point at
which it connects; but once all consumers have seen a message
Hello,
I analyzed if it is possible to broadcast messages using a single queue. I
know I could make the consumers listen to a topic but I noticed that a
temporary queue is created on the broker and I'm afraid of the broker
performance if hundreds of consumers listen to the topic.
So far, I manage
Hello,
Thank you for your answers. It's a lot clearer for me how the JDBC behaves
now. You can find in blue the answers to your questions below.
Regards,
Antoine
-Original Message-
From: Rob Godfrey [mailto:rob.j.godf...@gmail.com]
Sent: vendredi 6 janvier 2017 15:52
To: users@qpid.apach
On 09/01/17 07:50, Jeff Donner wrote:
Hi,
I want to authenticate the admin tools to qpidd with SSL + SASL EXTERNAL,
which so far looks something like this:
qpid-config --broker amqps://dev-qpidclient@localhost:5672 \
--ssl-certificate=pki/client/certs/client-cert.pem \
Great!
I'll try checking Jira first next time :-)
2017-01-09 10:09 GMT+01:00 Robbie Gemmell :
> Already added for the next release,
> https://issues.apache.org/jira/browse/QPIDJMS-240.
>
> On 9 January 2017 at 09:02, Milano Nicolum wrote:
> > Hi, I'd like to present an idea of configurable daemo
Already added for the next release,
https://issues.apache.org/jira/browse/QPIDJMS-240.
On 9 January 2017 at 09:02, Milano Nicolum wrote:
> Hi, I'd like to present an idea of configurable daemon nature of "QpidJMS
> Connection Executor" threads created in JmsConnection. Currently we're
> using Qpi
Hi, I'd like to present an idea of configurable daemon nature of "QpidJMS
Connection Executor" threads created in JmsConnection. Currently we're
using Qpid JMS client 0.11.1 on our company's devices for messaging. The
thing is we prefer to handle device/JVM shutdowns on our own. And nondaemon
threa
27 matches
Mail list logo
