On 11/23/18 11:01 AM, Robbie Gemmell wrote:
Hi folks,
I have put together a spin for a Qpid Proton-J 0.31.0 release, please
test it and vote accordingly.
The files can be grabbed from:
https://dist.apache.org/repos/dist/dev/qpid/proton-j/0.31.0-rc1/
The maven artifacts are staged for now at:
On Fri, 23 Nov 2018 at 16:01, Robbie Gemmell wrote:
>
> Hi folks,
>
> I have put together a spin for a Qpid Proton-J 0.31.0 release, please
> test it and vote accordingly.
>
> The files can be grabbed from:
> https://dist.apache.org/repos/dist/dev/qpid/proton-j/0.31.0-rc1/
>
> The maven artifacts
Hi folks,
I have put together a spin for a Qpid Proton-J 0.31.0 release, please
test it and vote accordingly.
The files can be grabbed from:
https://dist.apache.org/repos/dist/dev/qpid/proton-j/0.31.0-rc1/
The maven artifacts are staged for now at:
Hi,
Sorry about the DST, I didn't verify that part of the problem myself when I
got this thing to solve and included it as a (bad) example so it probably
doesn't cause any erratic behaviour in J-Broker.
My problem more specifically manifests itself in a server pair where time
(among other
Hi Olivier,
I am sorry for the inconveniences caused by provided preferences
stores configured by default in JDBC system config.
I committed changes against QPID-8260 fixing the issue with
provided preferences stores in DERBY and JDBC system configs.
As Rob has suggested already, you can
The connection timeouts are defined by the AMQP protocol and, since in
general the two ends of the connection would be on different machines,
implicitly refer to externally observable time (to the extent that such a
concept is meaningful).
You are changing the literal system time in your system,
I verified that system.currentTimeMillis returns walltime instead of
monotonic time so it cannot be used to calculate timeouts.
The problem here concerns every situation where walltime has shifted somehow
and adjusted back, for example when system clock is somehow drifted enough
and NTP is used
