I will try to get that information to you asap. Do you know if this error
messages signifies something impactful? Functionally, the broker appears to
be doing fine. Our throughput has not not decreased and most vitals, e.g.
heap memory, look okay.
--
Sent from: http://qpid.2158936.n2.nabble.com/
Hi Timo,
Surprisingly, you can "auto-create" both your main queue and dead letter queue
using auto-creation policies.
For instance, for your main queues you can create policy matching regular
expression like so "^.*(? wrote:
> Hi,
>
> I'm trying to set up qpid broker-J so that each of my queu
There were 5 binding +1 votes, 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.
Thanks to everybody for testing/voting.
+1
* Validated signatures and checksums
* Checked for presence of LICENSE and NOTICE files
* Ran mvn apache-rat:check, no files with missing license headers found.
* Built from source against Proton 0.28.0 in Fedora 29 and ran system tests.
On Fri, Jun 7, 2019 at 11:23 AM Ganesh Murthy wrote:
>
>
+1 from me
build and unit test on Ubuntu 18 ok
oslo.messaging smoke test ok
On Fri, Jun 7, 2019 at 11:24 AM Ganesh Murthy wrote:
> Hello All,
> Please cast your vote on this thread to release RC1 as the
> official Qpid Dispatch Router version 1.8.0.
>
> RC1 of Qpid Dispatch Router ve
On Tue, Jun 11, 2019 at 12:21 PM Michael Goulish
wrote:
> executive summary: I change my vote to *+1*
>
> but with JIRAs.
>
>
> OK! I have something.
>
> I didn't remember it, but my notes show that I have seen this exact failure
> before, also after a clean install.
> ( I mean the authz failu
That would be the very point that I corrected myself on earlier, where
I had somehow misread the second question numbered 2 originally. Per
the correction, the same answer to the first question 2 applied there
also, which was "This is the same as the default. Persistent messages
will be sent synchr
Hi Robbie,
Based on your input, i did some testing and got different test result in
terms of TPS(transaction per second) for below conditions
1. jms.forceSyncSend=true + send(jmsMsg, PERSISTENT, DEFAULT_PRIORITY,
DEFAULT_TIME_TO_LIVE) -- > I got TPS around 1200.
2. NO Setting @Connection Level
executive summary: I change my vote to *+1*
but with JIRAs.
OK! I have something.
I didn't remember it, but my notes show that I have seen this exact failure
before, also after a clean install.
( I mean the authz failure. The other one, the http failure is already
explained.)
So this means
On Tue, Jun 11, 2019 at 11:58 AM Michael Goulish
wrote:
> Of course I will not change my vote based on a suggestion ( from me and
> Gordon ) that the failure I am seeing might be caused by a missing
> package.
>
> What I will do is start looking into this to see if that is indeed the
> case.
> An
On 11/06/2019 3:56 pm, Michael Goulish wrote:
And this leaves the authz failure -- which could be due to some missing
package, except that the build system should detect those & throw a warning
so I have some way to fix.
You can get more information about the test failures from the various
log
Of course I will not change my vote based on a suggestion ( from me and
Gordon ) that the failure I am seeing might be caused by a missing
package.
What I will do is start looking into this to see if that is indeed the case.
And then we will make a change that detects and warns about that case.
An
+1
* Checked checksums
* Build/test Fedora 29, python 3
* Fails system_tests_http (known problem, not a regression)
* Build/test Fedora 28, python 2
* Occasional test fail system_tests_fallback_dest
known problem in new test code and not in mission code; fix is already on
master; not a r
On Tue, Jun 11, 2019 at 11:01 AM Gordon Sim wrote:
> On 11/06/2019 3:56 pm, Michael Goulish wrote:
> > My version of libwebsockets is 3.1.0-2, which is the version with a known
> > crash here (Gordon pointed out), but then we should detect that and skip
> > the test, rather than show a failure.
On 11/06/2019 3:56 pm, Michael Goulish wrote:
My version of libwebsockets is 3.1.0-2, which is the version with a known
crash here (Gordon pointed out), but then we should detect that and skip
the test, rather than show a failure.
And this leaves the authz failure -- which could be due to some
My version of libwebsockets is 3.1.0-2, which is the version with a known
crash here (Gordon pointed out), but then we should detect that and skip
the test, rather than show a failure.
And this leaves the authz failure -- which could be due to some missing
package, except that the build system sh
Hi Robbie,
Thank you so much for your all inputs. I really appreciate your fast
response.
We are doing testing based on your inputs. We will come back again, if we
have any other questions.
Regards,
Abhishek Kumar
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.htm
I ran the server example against rabbitmq (with a modified client to get
around the lack of support for dynamic addresses). It looks like the
issue is that rabbit responds to a detach with close=true by sending a
detach without setting the close.
The qpid::messaging client uses proton and curr
* -1*
I built against latest released proton ( 0.28.0 ) and I am running on a
new clean-install of Fedora 30.
I have two test failures.
I imagine that the 100% authz failure is because I do not have something
installed, but there were no warnings from cmake.
Here's the output:
97% tests
Hi Sidarth,
It looks like a defect to me.
Can you provide any code reproducing the issue? Any sample app or test case
would be of great help?
Any information about your consumption use case would be helpful as well.
Kind Regards,
Alex
On Mon, 10 Jun 2019 at 22:05, sidarthsc
wrote:
> Hi,
>
>
On 07/06/2019 4:23 pm, Ganesh Murthy wrote:
Hello All,
Please cast your vote on this thread to release RC1 as the
official Qpid Dispatch Router version 1.8.0.
RC1 of Qpid Dispatch Router version 1.8.0 can be found here:
https://dist.apache.org/repos/dist/dev/qpid/dispatch/1.8.0-rc1/
On Mon, 10 Jun 2019 at 16:30, Robbie Gemmell wrote:
>
> We discussed much of this last year already, the situation hasn't
> changed any since then.
>
> Initial summary points here, then more comments inline below.
>
> - Providing a CompletionListener is an explicit request that the send
> be async
22 matches
Mail list logo
