Hi Paul,
I managed to rsolve this one yesterday - switching from Proton version 0.17
to Proton version 0.23 allowed the build to complete successfully.
Thanks and regards,
Michael
On Thu, Jun 7, 2018 at 5:38 AM, Flores, Paul A.
wrote:
> Hi Michael,
>
>
> Sorry for slow response. I have had som
+1
* Validated signatures and checksums
* Check for license and notice files
* Built from source and ran the tests
On 06/07/2018 05:01 PM, Ganesh Murthy wrote:
Hello All,
Please cast your vote on this thread to release RC6 as the
official Qpid Dispatch Router version 1.1.0.
RC6 o
On 06/06/2018 01:04 PM, Robbie Gemmell wrote:
Seems reasonable. I assume you mean warning at startup only if they
are actually using the legacy store.
Yes, correct. Sorry I was not more clear. If the legacystore module is
loaded by qpid, then a warning-level deprecation notice will appear when
On 7 June 2018 at 23:44, Justin Ross wrote:
> On Tue, Apr 17, 2018 at 9:10 AM Gordon Sim wrote:
>
>> I think Ted is right that the feature did not reach that goal. It is not
>> sufficiently clear what is going on and on balance doesn't I think
>> justify the potential annoyance.
>>
>> However I d
This isn't currently possible with Qpid JMS. Supporting it would
require modifying the client code to make significantly more use of
Netty's SSL functionality, in place of the standard Java elements, so
that Netty can be configured for which provider to use underneath.
On 8 June 2018 at 12:17, w
Your expectation was incorrect. That config toggle existed from before
the clients implementation of JMS 2.0 and only controls behaviour of
send calls made without a CompletionListener in place. Specifically,
it forces sync sends for non-persistent messages and inside a
transactions. The explicitly
I think you need to step back and establish the reliability guarantees
you need first. On the one hand you are looking for exceptions to be
indicated per send, and on the other you are forcing async sends via
the synchronous send method, which doesnt guarantee reliability at its
most basic level.
Hi Robbie,
While I am using -
*forceSyncSend=true*
and with a CompletionListener, I would expect the callback event to come on
the same thread that invoked the send(), however in my observation - I am
sending the message using the main thread and I am getting a response on to
the
JmsSession [I
The vote is cancelled due to a discovery of another critical defect:
https://issues.apache.org/jira/browse/QPID-8207
I will fix the defect and spin another release.
-1
I found another critical defect in evaluation of flow to disk threshold:
https://issues.apache.org/jira/browse/QPID-8207
I would like to cancel this vote and spin another RC with a fix for
the found defect.
On 7 June 2018 at 16:15, Oleksandr Rudyy wrote:
> Hi all,
>
> I have put together a
Hi Chuck,
Thanks for your quick response!
I've pulled the latest commits from master and it fixed the issue! :)
Thanks again,
Sebastien.
On Fri, Jun 8, 2018 at 2:31 AM, Chuck Rolke wrote:
> Hi,
>
> I cut and pasted your configuration and it came up OK. The console trace
> for startup is appen
Hi Robbie,
Thanks a lot for your reply and clarification. You are right for threading
issue on "onException()". I am still doing R&D with your suggestion, i will
come back to you shortly with results.
Today morning at 10:55AM(UTC+1), i have taken master code and installed
locally "0.33.0-SNAPSHOT
ActiveMQ Artemis allows the configuration of BoringSSL as SSLProvider via
netty-tcnative. See
https://activemq.apache.org/artemis/docs/latest/configuring-transports.html
(https://activemq.apache.org/artemis/docs/latest/configuring-transports.html)
Since QPid JMS is also based on Netty I am wond
13 matches
Mail list logo
