+1
* verified all checksums
* ran apache-rat:check on source bundle
* compiled source and ran tests with the java-mms.0-9-1 profile
* build docs and viewed some pages
* run binary (tar.gz) broker and
** put BDB JE 7.4.5 on the class path and create a JSON/BDB VirtualHost(Node)
** checked the web
+1
My testing:
* check all checksums on source and binary bundles
* run apache-rat:check
* build and run all tests of the source bundle
* run Spout/Drain example against Qpid Broker-J (git master)
On Wed, Nov 15, 2017 at 4:59 PM, Oleksandr Rudyy wrote:
> Hi all,
>
> I
Welcome Chris,
Good to have you on the team!
On Wed, Nov 15, 2017 at 7:02 PM, Adel Boutros wrote:
> Welcome Chris!!
>
> From: Chris Richardson
> Sent: Wednesday, November 15, 2017 3:20:43 PM
> To: users
> Subject: Re:
+1
My testing:
1) Verify md5/sha checksums on tar.gz source and binarys
2) run test profile dby.0-9-1
3) shared durable subscriptions with the JMS client over TLS
4) start embedded broker using the staging repo and publish and receive msg
(using JMS client)
5) some tyre kicking in the Web
On Tue, 2017-11-07 at 10:43 +, Rob Godfrey wrote:
> On 7 November 2017 at 10:26, Lorenz Quack <quack.lor...@gmail.com> wrote:
>
> >
> > On Tue, 2017-11-07 at 09:51 +, Robbie Gemmell wrote:
> > >
> > >
> > > Hi Lorenz,
> > >
On Mon, 2017-11-06 at 10:14 +, Robbie Gemmell wrote:
> On 3 November 2017 at 16:58, Rob Godfrey <rob.j.godf...@gmail.com> wrote:
> >
> > On 1 November 2017 at 10:16, Lorenz Quack <quack.lor...@gmail.com> wrote:
> >
> > >
> > > Hi,
> >
, Lorenz Quack wrote:
> Hi,
>
> I think this is a broker issue.
> At least for the SCRAM authentication provider.
> Vavricka, could you confirm that you are using a SCRAM authentication
> provider on the broker?
>
> In SCRAM "=" and "," are specially en
Hi,
I think this is a broker issue.
At least for the SCRAM authentication provider.
Vavricka, could you confirm that you are using a SCRAM authentication provider
on the broker?
In SCRAM "=" and "," are specially encoded in usernames and passwords.
It looks like the broker is doing this
Welcome Adel!
Looking forward to your continued contributions!
On Wed, 2017-08-09 at 11:49 +0100, Robbie Gemmell wrote:
> The Qpid PMC have voted to grant commit rights to Adel Boutros in
> recognition of continued contributions to the project.
>
> Welcome, Adel!
>
>
Hi,
tests performed:
* verify checksums and signatures
* mvn apache-rat:check
* build from source
* run tests from source (mvn verify)
1 test failure.
-> Robbies analysis indicates no client issue
* run tests of bin release examples
* run HelloWorld from bin release against
Hi Robbie,
I just started testing the Qpid JMS 0.24.0 RC.
While compiling the src bundle and running the tests I got a test failure.
In the root project folder I ran:
mvn verify
The test in question is:
Tests run: 3, Failures: 0, Errors: 1, Skipped: 1, Time elapsed: 31.944 sec <<<
Hi all,
tl;dr
=
I think overall if it would come to a vote right now I would vote like this:
a) -1
b.1) -1
b.2) +0
c) +1
reasoning follows inline:
On Wed, 2017-08-02 at 15:13 +0100, Keith W wrote:
> If we were to add a feature to help the use-case, we'd need to decide
> on the scope.
>
>
Thanks, Irina.
On Wed, 2017-07-26 at 16:21 -0400, Irina Boverman wrote:
> Updated to include missing .bat files.
> --
> Regards, Irina.
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail:
a specific characteristics such as importance
> * Impacted Message details to include:
> ** sender information
> ** timestamp when message was originally received
> ** message characteristic used in determination action
> Just an idea.
>
> Paul
>
> From:
-7815 to reference this discussion.
Kind regards,
Lorenz
On Tue, 2017-06-13 at 10:21 +0100, Lorenz Quack wrote:
> Hello all,
>
> QPID-7815 [1] proposes the addition of a Queue Overflow Reject Policy
> to the Qpid broker-j (aka Qpid Broker for Java) component.
>
> Queue's allow
> have been dropped if needed. To Adel's point, the operator would need
> > to do pretty much the same the broker itself would; by making some
> > aribtrary decision such as the first or last messages on the
> > queue.
> >
> > Robbie
> >
> > On 13 June
gt; B) He would explicitly choose to ignore current overflowing messages
>
> C) He would explicitly define a period after which current overflowing
> messages would be deleted (A would be a specific implementation of C)
>
>
> Regards,
>
> Adel
>
> ___
Hello all,
QPID-7815 [1] proposes the addition of a Queue Overflow Reject Policy
to the Qpid broker-j (aka Qpid Broker for Java) component.
Queue's allow to define overflow limits (in term of number of messages
and/or cumulative size of the messages). If the limit is breached the
overflow
The Apache Qpid (https://qpid.apache.org) community is pleased to announce
the immediate availability of Apache Qpid for Java 6.1.3.
This release incorporates a number of defect fixes and enhancements in
Qpid Broker for Java and the JMS AMQP 0-x Client.
The release is available now from our
The Apache Qpid (https://qpid.apache.org) community is pleased to announce
the immediate availability of Apache Qpid for Java 6.0.7.
This release incorporates a number of defect fixes and enhancements in
Qpid Broker for Java and the JMS AMQP 0-x Client.
The release is available now from our
There were 4 binding +1 votes, with no other votes received. The vote
has passed.
The voting thread can be found at:
http://qpid.2158936.n2.nabble.com/VOTE-Release-Qpid-Java-6-0-7-RC1-tp7663488.html
I will add the archives to the dist release repo and release the maven
staging repo shortly. I
There were 5 binding +1 votes, with no other votes received. The vote
has passed.
The voting thread can be found at:
http://qpid.2158936.n2.nabble.com/VOTE-Release-Qpid-Java-6-1-3-RC1-tp7663508.html
I will add the archives to the dist release repo and release the maven
staging repo shortly. I
+1
* checked checksums
* compiled & ran the Spout and Drain examples against the binary broker
On Thu, 2017-05-25 at 17:39 +0100, Keith W wrote:
> Hi all,
>
> A release candidate for the next release (6.0.7) of the Qpid Java
> Components has been created.
>
> The list of defect fixes can be
making my +1 explicit
On Fri, 2017-05-26 at 16:39 +0100, Lorenz Quack wrote:
> Hi all,
>
> As Rob pointed out my previous mail contained an error.
> This email thread is (as the subject suggests) a voting thread for
> the release candidate for the 6.1.3 release and not fo
/repositories/orgapacheqpid-1108
On Fri, 2017-05-26 at 13:49 +0100, Rob Godfrey wrote:
> The title and links say 6.1.3 but the body of the e-mail says 6.0.7 ... You
> might want to resend and make clear :-)
>
> -- Rob
>
> On 26 May 2017 1:44 pm, "Lorenz Quack&q
Hi all,
A release candidate for the next release (6.0.7) of the Qpid Java
Components has been created.
The list of defect fixes can be found in Jira:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20QPID%20AND%20fixVersion%20%3D%20qpid-java-6.1.3
Please test and vote accordingly.
t; level description of the approach will be very helpful for us in order to
> brainstorm our use cases along with this solution.
>
> - Ramayan
>
> On Fri, Apr 28, 2017 at 9:34 AM, Lorenz Quack <quack.lor...@gmail.com>
> wrote:
>
> > Hello Ramayan,
> >
>
Hello Ramayan,
We are still working on a fix for this issue.
In the mean time we had an idea to potentially workaround the issue until a
proper fix is released.
The idea is to decrease the qpid network buffer size the broker uses.
While this still allows for sparsely populated buffers it would
://svn.apache.org/repos/asf/qpid/qpid-jms-amqp-0-x
Thanks to everyone involved.
Kind regards,
Lorenz
On Thu, 2017-04-20 at 16:10 +0100, Lorenz Quack wrote:
> A brief update.
> The migration is progressing nicely.
> We resolved the issue with the client history. It will be fully preser
Hello All,
We would like to notify all committers that we are starting the
svn to git migration of the Qpid Broker-J and Qpid JMS AMQP 0-x
components as discussed in [1].
Please do not commit to [2] and/or [3] or any subfolders until
further notice.
Kind regards,
Lorenz Quack
[1]
http://qpid
On Tue, 2017-04-18 at 09:49 +0200, Rob Godfrey wrote:
> On 17 April 2017 at 17:41, Robbie Gemmell
> wrote:
>
> >
> > Sounds good to me.
> >
> > On 14 April 2017 at 14:54, Oleksandr Rudyy
> > wrote:
> > >
> > > Hi all,
> > >
> > > As per vote [1]
+1
On 04/04/17 13:44, Keith W wrote:
As already proposed and discussed in the following thread:
http://qpid.2158936.n2.nabble.com/DISCUSS-Migrate-Qpid-Broker-for-Java-and-Qpid-JMS-AMQP-0-x-Client-from-SVN-to-GIT-tt7661505.html#none
In summary, the proposal is:
Qpid Broker J:
Current SVN
On 03/04/17 14:53, Keith W wrote:
On 31 March 2017 at 10:57, Rob Godfrey <rob.j.godf...@gmail.com> wrote:
On 30 March 2017 at 12:32, Lorenz Quack <quack.lor...@gmail.com> wrote:
+1 on the migration to git.
Regarding the name of the broker's git repo:
* qpid-broker: I agree
fferent thread but it will assume the same name.
May I ask why you want to identify a thread beyond the task that it is
performing?
Kind regards,
Lorenz
On 03/04/17 09:18, Lorenz Quack wrote:
Hi,
I have not tried this before but a quick web search suggests [1, 2]
you could achieve this b
Hi,
I have not tried this before but a quick web search suggests [1, 2] you
could achieve this by means of a custom converter.
Regarding Houskeeping threads sharing the same name, on trunk this
should no longer be the case.
If you encounter other thread pools with this behaviour please flag it
+1 on the migration to git.
Regarding the name of the broker's git repo:
* qpid-broker: I agree with others that this might lead to confusions
with the cpp broker.
* qpid-java-broker: I am worried that legal will not be happy with this
since Java is a trademark. See [1] and [2].
* This
all artifacts listed.
Regards,
Adel
____
From: Lorenz Quack <quack.lor...@gmail.com>
Sent: Monday, March 20, 2017 11:08:44 AM
To: users@qpid.apache.org
Subject: Re: Corrupt artifacts on Qpid release web page
Hello Adel,
That is not the link to the actual fil
chiver):
I can extract qpid-java-6.1.1.tar.gz to qpid-java-6.1.1.tar
I cannot extract qpid-java-6.1.1.tar (Archive is broker or damaged)
Regards,
Adel
From: Lorenz Quack <quack.lor...@gmail.com>
Sent: Monday, March 20, 2017 10:13:59 AM
To: users@qpid.apache
Hi,
I just tried the source bundle of the "Qpid for Java 6.1.1," release
without issues.
I used the command
$ tar xfz qpid-java-6.1.1.tar.gz
to unpack the source bundle.
With which artefacts do you experience problems specifically?
What tools are you using to extract the files?
Windows,
Hi,
I have never touched those components. I haven't even looked into them.
Taking into account what Keith said about the code being pretty much
dead already
I am +1 for the removal in the next *minor* [1] release 6.3.0.
Kind regards,
Lorenz
[1] http://semver.org/
On 19/03/17 22:54, Keith
ention the checksums once I test it. I think it
should move in this release. Theres no need to respin for that, you
can just generate them and add them to the dist repo.
On 16 March 2017 at 10:04, Lorenz Quack <quack.lor...@gmail.com> wrote:
+1
* verified checksums
* build from source
* Ran joram te
was wondering if somebody has
already done some of it.
Thanks again
On Wed, Mar 1, 2017 at 5:35 AM Lorenz Quack <quack.lor...@gmail.com> wrote:
Hello Dan,
I cannot comment too much on what you have to do on the CloudFoundry
(CF) side of things but I might be able to give some advice from th
Hello Dan,
I cannot comment too much on what you have to do on the CloudFoundry
(CF) side of things but I might be able to give some advice from the
Qpid Broker for Java side.
For authentication, the broker supports OAuth2 [1] which is also
supported by CF [2]. Qpid uses the implicit grant
Hello Rabih,
Unfortunately, the v7 release is still a couple of months away.
Out of curiosity, what is your time-line for when you would like this
feature to land?
We were considering back porting this but there are currently no plans
for a 6.2.0 release and as a new feature this is not
Hello Pat,
What components are you using?
C++ broker, Java Broker?
Which client?
You said "The broker had flow control thresholds set accordingly". Can
you elaborate what exactly you did?
Kind regards,
Lorenz
On 31/01/17 00:24, Demoss, Patrick wrote:
I was surprised to see certain behavior
g a "This closes #" message somewhere in their log. The
PR process for the ASF's GitHub mirrors works essentially the same for
the svn based repos as it does for the Git based repos (asuming you
are actually using git-svn, which I believe many/most folks are?).
Robbie
On 30 January 2
I think it is different for different components of Qpid.
The Qpid broker for Java for example has not migrated its main
repository to git.
Also the GitHub mirror is treated as read-only. And it is quite possible
that pull request might go unnoticed.
So, for the Qpid broker for Java component
+1
* validated the checksums
* built from source & ran tests
* ran Hello World example against Qpid Broker for Java 6.1.1
On 16/01/17 18:38, Robbie Gemmell wrote:
Hi folks,
I have put together a spin for a 0.20.0 Qpid JMS client release,
please test it and vote accordingly.
The source and
On 12/01/17 16:07, Robbie Gemmell wrote:
On 12 January 2017 at 15:21, Lorenz Quack <quack.lor...@gmail.com> wrote:
Hello,
Robbie, Rob, Alex, and I had a discussion on IRC yesterday about the Qpid
Broker for Java support for JMS 2.0 shared subscriptions.
This is a follow-u
Hello,
Robbie, Rob, Alex, and I had a discussion on IRC yesterday about the
Qpid Broker for Java support for JMS 2.0 shared subscriptions.
This is a follow-up from that discussion.
We discussed that it would be helpful to have a document describing the
broker behaviour purely in AMQP 1.0
.
Robbie
On 11 January 2017 at 10:21, Lorenz Quack <quack.lor...@gmail.com> wrote:
Hello again,
Alex just pointed out to me that I missed an important part of
the JMS 2.0 spec. In chapter 8.3 it says:
A shared non-durable subscription is identified by a name
specified by the
ns without a
ClientID can use.
I think this was addressed by my second email and leads me to think
that we are now in agreement.
Kind regards,
Lorenz
On 11 January 2017 at 08:51, Lorenz Quack <quack.lor...@gmail.com> wrote:
Hello,
Sorry for the slightly lengthy email.
tl;dr: I
conflict with
anything
Kind regards,
Lorenz
On 11/01/17 08:51, Lorenz Quack wrote:
Hello,
Sorry for the slightly lengthy email.
tl;dr: I propose to change to the way JMS 2.0 subscriptions are
treated in the face of the (non-)existence of a clientId as
compared to what is outlined
Hello,
Sorry for the slightly lengthy email.
tl;dr: I propose to change to the way JMS 2.0 subscriptions are
treated in the face of the (non-)existence of a clientId as
compared to what is outlined in QPIDJMS-220.
Introduction:
=
I am working on adding support for
+1
The next Qpid Broker for Java is probably going to be 7.0 (i.e., a major
release) so now is as good a time as any.
Some dates for reference [1]:
Java VersionFirst ReleaseEnd of Public Updates
7Jul 2011Apr 2015
8Mar 2014Sep 2017
Hello Antoine,
Yes, it is expected that a new Connection is made for each enqueue and
dequeue.
The relevant code is
org.apache.qpid.server.store.AbstractJDBCMessageStore#getConnection
which is called from multiple places.
We do our performance testing using the BDB store. We do not
Hello Adel,
I think persisting arrival time for AMQP 1.0 messages was only recently
added (QPID-7575).
The other protocols should already support it.
If you observed this with protocol versions other than 1.0 I think this
is a bug in which case I would ask you to raise a JIRA.
Could you
sent) when running with Memory store. I
am wondering what does flow to disk does when we use Memory store?
Since our average messages size is less than 1KB, I am really looking
forward to some recommendation around the % allocation for DM vs Heap.
Thanks
Ramayan
On Tue, Dec 20, 2016 at 4:
+1
* checked all checksums
* started broker created queue via web management console
* ran Hello example
On 20/12/16 12:27, Keith W wrote:
Making my +1 explicit.
My testing was:
1) Verified the md5/sha checksums on all distribution artefacts
2) Verified signatures on all all distribution
Hello Ramayan,
glad to hear that the patch is (mostly) working for you.
To address your points:
1. If indeed in one case flow to disk is kicking in while in
the other one it is not, then I am not surprised that
there is a 5% difference. The question is whether the
flow
+1
In addition to what Alex did I also:
* checked the md5 and sha1 checksums
* created a simple query in the WMC
* created a simple dashboard in the WMC
On 19/12/16 15:18, Oleksandr Rudyy wrote:
+1
I performed the following testing of Qpid for Java 6.1.1:
* started the broker
* using Web
Hello Adel,
you would set this like any other attribute. something like this:
curl -u username localhost:8080/api/v6.1/broker -X POST -d
'{"confidentialConfigurationEncryptionProvider":"AESKeyFile"}'
However, we only allow valid values to be set. The error message from
that curl command will
+1
* checked sha1 checksums
* ran the joram test suite against the Qpid Broker for Java
One comment. The checksums do not contain the filenames so you cannot
run "sha1sum -c file.sha1".
IIRC, this is a shortcoming in the maven plugin. when doing Qpid for
Java releases we have a script that
.
Is the above in contradiction with what is said here "the AMQP 1.0 Qpid JMS Client
does currently not support message encryption"?
Regards,
Adel
____
From: Lorenz Quack <quack.lor...@gmail.com>
Sent: Tuesday, December 6, 2016 1:46:19 PM
To: users@qpid.apache
Hello Adel,
As mentioned by Keith, the AMQP 1.0 Qpid JMS Client does currently not
support message encryption.
Or did I misunderstand your follow-up question?
Furthermore, the Kerberos AuthenticationProvider also requires the full
strength JCE.
Kind regards,
Lorenz
On 06/12/16 09:13,
+1
* verified sha1 and md5 checksums
* created virtualhost and queue via WMC
* ran HelloWorld example
* used SCRAM-SHA-256 authprovider
* created Query, saved it and loaded it
* used https to test VirtualHost#publishMessage and found some issues
(QPID-7515) but I don't consider them blockers.
See [1] for the 6.0.5-RC1 release announcement.
Kind regards,
Lorenz
[1]
http://qpid.2158936.n2.nabble.com/Fwd-VOTE-Release-Qpid-Java-6-0-5-td7652349.html
On 20/10/16 16:34, Lorenz Quack wrote:
Hi Ram, Hi Alex,
I committed to fixes to the AMQP 0-10 code path under QPID-7465.
This should reduce
Hi,
While performing tests on this RC I found a couple of issues (and I have
not concluded my testing yet).
I think some of the issues found are serious enough to block this release.
Therefore I vote to retract this RC.
-1
Kind regards,
Lorenz
List of issues found so far:
*
this
down.
Kind regards,
Lorenz
On 19/10/16 16:54, rammohan ganapavarapu wrote:
Thank you!!
On Wed, Oct 19, 2016 at 4:15 AM, Lorenz Quack <quack.lor...@gmail.com>
wrote:
Hi Ram, Hi Alex,
thanks for sending me your example code and logs.
I am now able to reproduce and I am i
Hi Ram, Hi Alex,
thanks for sending me your example code and logs.
I am now able to reproduce and I am investigating now.
It currently looks like there is a defect somewhere in the AMQP 0-10
code path.
I will keep you posted.
Kind regards,
Lorenz
On 18/10/16 22:13, rammohan ganapavarapu
it back to dl queue.
Q: Are the messages persistent or transient?
A: They are persistent.
Ram
On Mon, Oct 17, 2016 at 1:15 AM, Lorenz Quack <quack.lor...@gmail.com>
wrote:
Hello Ram,
This seems curious.
Yes, the idea behind flow to disk is to prevent the broker from running
out of direct memory.
Th
Hello Ram,
may I refer you to the relevant section of the documentation [1].
As explained there in more detail, the broker keeps a representation of
each message in heap even when flowing the message to disk.
Therefore the amount of JVM heap memory puts a hard limit on the number
of message
Hi Ram,
Notice that in your example both QPID_WORK and qpid.work_dir are specified.
It seems that currently QPID_WORK take precedence.
I guess if the environment variable and system property QPID_WORK are not
set then the broker picks up the qpid.work_dir property, right?
Kind regards,
Lorenz
Hello Bhargav,
there is no "best value" for heartbeating. It all depends.
Normally a TCP does not need heartbeating at all. It is usually
used for two purposes
* a simplistic sanity check that the other side is in a healthy
state (e.g., does not "hang")
* to prevent NATs or firewall from
Hello Ramayan,
by common convention deprecated features eventually get removed
after a deprecation period. I don't know exactly when JMX was
first deprecated but in 6.0.x we stepped up the deprecation level
by removing the documentation and the JMX ports from the default
configuration.
Hi Ramayan,
That is not entirely correct.
Flow to Disk is only indirectly related to persistence.
Persistent messages are *always* written to the message store
before the message is acknowledged or the transaction completes.
However, for performance reasons the broker will keep a copy of
the
+1
* verified sha1 and md5 checksum
* started a java broker and sent / consumed some ad-hoc messages
* verified that channel_flow (aka producer side flow control
QPID-6567) feature works
Kind Regards,
Lorenz
On 17/08/16 15:09, Justin Ross wrote:
The artifacts proposed for release:
HI Ram,
I'm afraid that in 0.28 there is no way to only query specific
attributes or statistics.
Starting with 6.1 we Qpid for Java will support some SQL-like query
capabilities but in 0.28 there is no such thing.
Kind Regards,
Lorenz
On 12/08/16 23:20, rammohan ganapavarapu wrote:
Hi,
On 15/07/16 09:56, Robbie Gemmell wrote:
On 15 July 2016 at 09:16, Justin Ross wrote:
I've been working with the security pages recently, and there are two
things I propose.
First, I'd like to simplify the way we include the full CVE content.
Instead of embedding it in
Hi,
* Verified all the md5 and sha1 checksums
* Started broker & poked around in the web management console
* Run hello world example
While poking around I found a couple issues which are not regressions
and I don't consider blockers:
* Help Menu link is broker (unexpanded context variable)
*
Hello Simon,
I'm sorry I am not familiar with most of the components you mention in
your report.
But I did noticed that in the stacktrace you see this:
org.apache.servicemix.bundles.qpid:0.28.0.1
That made me think maybe servicemix is bundling version 0.28 of the Qpid
Java client
Hi,
I believe the first issue was fixed as part of QPID-7112 [1] but the fix
has not been backported so will only be part of 6.1.
Kind Regards,
Lorenz
[1]
CVE-2016-3094: Apache Qpid Java Broker denial of service vulnerability
Severity: Important
Vendor: The Apache Software Foundation
Versions Affected: Qpid Java Broker versions 6.0.0, 6.0.1, and 6.0.2
Description: A malformed authentication attempt may cause the broker to
terminate. The Qpid
+1
I did the following successful testing:
* run the unit and sys tests with the bdb.0-9 profile
* ad hoc testing on linux
* ad hoc testing on windows
* verified sha1 and md5 sums
On 19/05/16 12:04, Oleksandr Rudyy wrote:
Hi all,
I have built RC3 for 6.0.3 Qpid Java Components.
The
On 16/05/16 22:55, Rob Godfrey wrote:
On 16 May 2016 at 18:27, Gordon Sim wrote:
On 16/05/16 18:23, Rob Godfrey wrote:
On 16 May 2016 at 18:21, Gordon Sim wrote:
One further point to mention, a message sent over 0-10 to a queue could
not be received
On 16/05/16 11:44, Robbie Gemmell wrote:
On 16 May 2016 at 10:59, Robbie Gemmell wrote:
On 12 May 2016 at 16:41, Keith W wrote:
Hi all,
A release candidate for the next release (6.0.3) of the Qpid Java
Components has been created.
The list
+1
On 30/03/16 11:25, Robbie Gemmell wrote:
Hello folks,
Many moons ago, a seperate mailing list was established for Proton,
back when it was purely a protocol engine other components would use.
Its scope has since expanded beyond that and the separate mailing list
has I feel been an
Hi Julien,
As I alluded to in my other eMail, PUT can be used for both creation and
modification.
The specification [1] has the following to say:
"The PUT method requests that the state of the target resource be
created or replaced with the state defined by the representation
enclosed in
On 07/03/16 08:14, Rob Godfrey wrote:
On 7 March 2016 at 07:06, Julien Charon wrote:
Indeed, copy paste error on this, sorry. I observed the behaviour not only
for DELETE, but also for PUT.
I.e. if I try to create a new queue and use a name of a queue that already
On 22/02/16 11:51, Oleksandr Rudyy wrote:
Hi everyone,
I created a new 6.0.1 RC3 build containing a fix for a blocker:
QPID-6817 - [Java Broker] On abrupt connection close from client side when
Broker is delivering messages to consumer, the delivering messages might
not be released as part
On 23/02/16 12:08, Gordon Sim wrote:
On 23/02/16 10:42, Lorenz Quack wrote:
On 22/02/16 18:36, Gordon Sim wrote:
What does the java broker use the sasl interchange for? Does it allow
AMQP connections to specify XOAUTH2?
Yes. In this scenario you would specify the access token as a password
On 22/02/16 18:36, Gordon Sim wrote:
*snip*
(Is there a SASL interchange defined for OAuth2?)
There are 2 different SASL mechanisms that have been put forward,
which are
detailed on the JIRA (with links to the definitions):
https://issues.apache.org/jira/browse/QPID-7045. I believe
+1
On 03/12/15 15:06, Oleksandr Rudyy wrote:
Hi folks,
I would like to initiate new voting to release Qpid Java Components 6.0.0
RC5 as the final 6.0.0.
Maven release artifacts are available from maven staging repo at:
https://repository.apache.org/content/repositories/orgapacheqpid-1056
t;robbie.gemm...@gmail.com>
To: users@qpid.apache.org
Sent: Friday, October 9, 2015 3:26:50 PM
Subject: Welcome Lorenz Quack as a Qpid committer
The Qpid PMC have voted to grant commit rights to Lorenz Quack in
recognition of his contributions to the project.
Welcome,
web ui I can see vh as I created them
from ui.
Ram
On Oct 1, 2015 1:10 AM, "Lorenz Quack" <quack.lor...@gmail.com> wrote:
Hi Ram,
did you check the log files for errors?
The broker log is located in ${QPID_WORK}/log/qpid.log
Alternatively, did you check in the web managemen
quot;9099",
"protocols" : [ "JMX_RMI" ]
}, {
"id" : "8a5e84c5-110a-43cd-895c-936e0845d8b4",
"name" : "RMI_REGISTRY",
"port" : "8999",
"protocols" : [ "RMI" ]
} ],
uot;MANAGEMENT-JMX"
},
{
"httpBasicAuthenticationEnabled": true,
"name": "httpManagement",
"pluginType": "MANAGEMENT-HTTP"
}
],
"ports": [
{
n't seem that way since the modelVersion of your config is 1.3. I
believe 0.32 has model version 3.0.
cheers,
Lorenz
On 30/09/15 16:27, rammohan ganapavarapu wrote:
Lorenz,
I was trying to connect using python as below.
from qpid.messaging import *
broker = "localhost:5672&quo
Hello Ram,
By default you must authenticate with the broker before performing any
management operation to prevent unauthorized access.
The error seems to indicate that you did not do this.
When you use the browser you can login via
http://localhost:8080/login.html (assuming the broker is
Hello Patrick,
the message seems to suggest that the consumer on the master closes
while there are still messages in the pre-fetch queue. Those messages
will be requeued.
It is hard to tell why this is happening without knowing more about how
you are using JMS in your application.
How
1 - 100 of 105 matches
Mail list logo