A couple of suggestions spring to mind - I've experienced problems with
timers in other libraries where a timer fires after (or indeed during) its
callback or associated data has been deleted, resulting in a segfault.
Could this be relevant? Probably capturing a core dump and inspecting with
gdb
I've added a fix in ea46607e776062c8555ef24a74c48a9b12bf2ca9 that I
think sound resolve this. Sadly we need to -1 this release candidate
and spin a new one.
changing vote to -1
On 04/17/2018 06:49 PM, Keith W wrote:
With the 0.27.0 RC (and the Qpid JMS Client 0.31.0) I am noticing a
With the 0.27.0 RC (and the Qpid JMS Client 0.31.0) I am noticing a
java.lang.ArrayIndexOutOfBoundsException when PN_TRACE_FRM=true, which
did not occur with 0.26.0.
My JMS code fragment (based on HelloWorld).
Context context = new InitialContext();
ConnectionFactory factory =
Hi Bryan
I haven't seen problem reports raised against Broker-J regarding this error.
The error actually originates from the HA feature within Berkeley BDB JE.
There's a useful reply within the following thread that explains some
background about how the maximum clock delta is used.
On 13/04/18 20:03, Robbie Gemmell wrote:
Hi folks,
I have put together a spin for a Qpid Proton-J 0.27.0 release, please
test it and vote accordingly.
+1, built from source including all tests.
-
To unsubscribe, e-mail:
On 17/04/18 14:24, Ken Giusti wrote:
After thinking about the comments on this thread and
spending some time researching various "reliable multicast" solutions
I've come to the conclusion that we *should* allow multicasting
unsettled messages by having the ingress router provide the settlement.
Hello,
When I create a proton::container and use it, I have a crash when I delete
the proton object:
void pn_proactor_free(pn_proactor_t *p) {
-> DeleteTimerQueueEx(p->timer_queue, INVALID_HANDLE_VALUE);
I'm using proton 0.21 compiled in CXX03 mode.
Is anyone have an idea ?
Thank you,
Apologies for thread-jacking Ted's original email thread.
After thinking about the comments on this thread and
spending some time researching various "reliable multicast" solutions
I've come to the conclusion that we *should* allow multicasting
unsettled messages by having the ingress router