Just to be clear, AMQP 0-10 *requires* that a binding key is used to
uniquely identify every binding between an exchange and a queue. It does
allow for the fact that the binding may be the empty string, however only
one binding per queue may use this binding key on the given exchange. So I
don't
Hi Adel,
I'm a bit confused... you say
> As no consumer is connected to this queue, all messages are kept
in-memory which causes the OutOfMemory exception in the broker.
but then also say
> Consumer connected to that queue (Is it the dispatcher?):
> Name: qdlink.OyY41QAJRZ4JGGg
> Mode: MOVE
Do
Hi Andreas,
unfortunately the Apache mailing list servers strip out images from mails
posted to the list - would it be possible for you to open a JIRA and attach
the image to that ?
thanks,
Rob
On 13 July 2016 at 07:57, Neustifter Andreas
wrote:
> Hi,
>
>
>
> I’m using qpid-cpp-0.34 (selfcompi
On 2 August 2016 at 21:21, Gordon Sim wrote:
> On 02/08/16 20:18, Ted Ross wrote:
>
>> Since this is synchronous and durable, I would expect the store to be
>> the bottleneck in these cases and that for rates of ~7.5K, the router
>> shouldn't be a factor.
>>
>
> I don't know anything about the ja
To expand on Lorenz's response:
JMX will continue to be supported in 6.0.x (although not enabled by
default) - I'd expect us to continue releasing bug fix releases on this
branch until at least the end of 2017 (so another 15 months). 6.1 and
beyond will no longer support JMX management.
There ar
Hi Ram,
So, firstly 0.28 is pretty old now - it was released at the beginning of
June 2014... how the broker handles messages in memory has changed
considerably since then. Historically the broker simply used soft
references to manage message memory consumption - that is when the JVM GC
decided t
Hi Ram,
yes - unfortunately the generic code we use for configuration parsing
doesn't have a way of understanding things like MB/GB ... nor does it allow
arithmetic operations. In practice I'd hope this particular value is only
changed by people who have done extensive testing and are very comfor
D, CRAM-MD5, PLAIN,
> AMQPLAIN, ANONYMOUS, XOAUTH2] Client restricted itself to : ANONYMOUS
> username=null
>
> Thanks,
> Ram
>
> On Tue, Apr 19, 2016 at 10:10 AM, rammohan ganapavarapu <
> rammohanga...@gmail.com> wrote:
>
> > Hi Rob,
> >
> > I did
use Anonymous and its working now. Now i need some
> documents or suggestions on how to configure Mem settings and flow to disk
> settings in config.json
>
> Thanks,
> Ram
>
> On Fri, Aug 26, 2016 at 12:16 PM, Rob Godfrey
> wrote:
>
> > Hi Ram,
> >
> > I assu
>From looking at your last log file we see the line
2016-08-25 22:46:25,819 DEBUG [QpidBrokerShutdownHook] (server.Broker) -
Shutdown hook running
The shutdown hook is run when the kill signal is received by the broker.
This would imply that the broker is being killed by an external actor (e.g.
a
issue.
>
> Do you have any clue how can I findout who could be killing qpid broker??
>
> Thanks
> Bhargav
>
>
>
>
> On Wed, Aug 31, 2016 at 2:14 PM, Rob Godfrey
> wrote:
>
> > From looking at your last log file we see the line
> >
> > 2016-08-25
this eye opener.
>
> Thanks
> Bhargav
>
>
>
>
> On Wed, Aug 31, 2016 at 4:30 PM, Rob Godfrey
> wrote:
>
> > How are you running the qpid-server.sh script? In the foreground (e.g.
> > "bin/qpid-server.sh"), the background (e.g. "bin/qpid-server.
472242532264
> > }, {
> > "id" : "881b3b25-463d-4efe-8b27-0335525ea920",
> > "name" : "RMI_REGISTRY",
> > "type" : "RMI",
> > "port" : "8999",
> > "lastUpdatedBy" :
Hi Adel,
On 7 September 2016 at 09:12, Adel Boutros wrote:
> Hello,
>
> I was playing around with the Rest API and noticed the logs generated are
> not always easy to understand.
> In my example, I tried to create twice the same queue expecting the second
> one to fail and it did. However when I
I think you should be able to escape characters in the username / password
with % encoding... so something like
amqp://PQ-RST-UV-W:VPN%3amwrst@clientid/localhost?brokerlist=...
should work (where %3a is the encoding of the : character).
The only problem I see (which shouldn't cause you an is
I'm afraid I can't answer your query directly... but you say you are
using "Qpid Broker 6.0.4" - does that mean the Qpid Broker for Java?
The Java Broker does its best to convert messages between AMQP
protocols so you should be able to use a client which speaks AMQP
0-9-1 or AMQP 1.0 from iOS and u
Hi Dominik,
AMQP 1.0 doesn't define a way of creating queues through the core
protocol - that will be in the future management specification, so
there isn't anything directly analogous to the {create always} syntax
(which causes the client to emit some AMQP 0-x commands)... however
the upcoming 6.
ion you suggest. *But* its
>> > > name is
>> > > "idle timeout". We can't easily change the name. I think we
>> > > should take
>> > > the spec text that goes with the name, and the behavior of our
>> > > components,
>> > > firm
Hi Vavricka,
I'm not sure I totally understand your question... if you have one
queue with two bindings and a message matches both bindings, the
message will still only be placed on the queue once.
Do you actually mean you have two queues, A and B, and A is bound to
the exchange with the key 'tes
> working, what is the default.json file under default/config folder? so if i
> wanted to specify my own vhost config how do i specify that when i start
> broker? can i use it as system property like below?
>
> -prop
> qpid.initial_config_virtualhost_config=/opt/initial_config_v
Hi Vavrinka,
the QMF2 plugin is not really supported any more for the Java Broker.
The preferred management mechanism is to use the REST API.
If you really want to use the QMF2 plugin, you can find the source
code here: https://svn.apache.org/repos/asf/qpid/trunk/qpid/tools/src/java
I've just up
Hi Ramayan,
this is exception indicates that a message has been deleted from the
store, but the in-memory queue still references it. Unfortunately the
exception doesn't really tell us anything about how the broker will
have got to this state.
Having looked at the code I have an idea about what m
I've added a patch file which should apply to 0.32 on the following
JIRA: https://issues.apache.org/jira/browse/QPID-7451
Hope this helps,
Rob
On 6 October 2016 at 22:04, Rob Godfrey wrote:
> Hi Ramayan,
>
> this is exception indicates that a message has been deleted from the
&g
d
> trigger the same bug?
>
> For the fix, would it be possible to fix it in 0.32 as well as in 6.0.x ?
>
> CCing, Helen from our team.
>
> Thanks,
>
> Ramayan
>
> On Thu, Oct 6, 2016 at 1:21 PM, Rob Godfrey wrote:
>
>> I've added a patch file which
> digging.
>
> For 0.32, we have patched the broker before so we will be able apply this
> patch (if we go that route). We are currently performance testing 6.0.4 and
> if that goes well, we will probably using the fix that you make in 6.0.x.
>
> Thanks
> Ramayan
>
> On
On 8 October 2016 at 20:17, rammohan ganapavarapu
wrote:
> Any help from any one?
>
> On Fri, Oct 7, 2016 at 1:35 PM, rammohan ganapavarapu <
> rammohanga...@gmail.com> wrote:
>
>> Rob,
>>
>> I know its a old post but i ran into this issue again, i have clients
>> create queues dynamically based o
rops
>> ../etc/qpidd.properties
>>
>> System Properties set to -Damqj.logging.level=info
>> -DQPID_HOME=/opt/qpid-java-broker -DQPID_WORK=/ebs/
>> QPID_OPTS set to -Damqj.read_write_pool_size=32 -DQPID_LOG_APPEND=
>> Using QPID_CLASSPATH /opt/qpid-java-broker/lib/*
In general context variables are used in two ways:
1) where the configuration file (or initial configuration) explicitly
uses a value of the for "${prop_name}"
2) where the code defines a default value for an attribute in terms of
a property (for instance the alertRepeatGap property of queues is
d
hat I can pass to create with
> ALWAYS for Java client?
>
> Ram
>
> On Oct 9, 2016 5:01 AM, "Rob Godfrey" wrote:
>
>> On 8 October 2016 at 20:17, rammohan ganapavarapu
>> wrote:
>> > Any help from any one?
>> >
>> > On Fri, Oct 7,
Looking at the code, in the startup phase the Broker seems to use only
QPID_WORK as provided in a system property, or qpid.work_dir provided
on the command line with the -prop qpid.work_dir=foo form. It seems
that it does not try to look for qpid.work_dir in the system
properties (or, implicitly,
On 11 October 2016 at 10:45, Robbie Gemmell wrote:
> From memory of how it used to [be intended to] work long ago,
> qpid.work_dir was a config property that could be set to influence the
> work dir actually used and was referenced in the config json etc
> accordingly, but if its value was not set
> > So "qpid.work_dir" doesn't take effect at the time of boot up? i have
> to
> > > set "
> > > QPID_WORK" environment variable?
> > >
> > > On Tue, Oct 11, 2016 at 2:45 AM, Rob Godfrey
> > > wrote:
> > >
> &g
On 13 October 2016 at 17:36, rammohan ganapavarapu
wrote:
> Lorenz,
>
> Thank you for the link, so no matter how much heap you have you will hit
> the hard limit at some point right?, i thought flow to disk will make
> broker not to crash because of out of memory issue but looks like its not
> th
e has flowed to disk, the
broker simply reloads individual messages into memory when it needs them in
an on-demand basis.
Hope this helps,
Rob
>
> Thanks,
> Ram
>
> On Thu, Oct 13, 2016 at 11:29 AM, Rob Godfrey
> wrote:
>
> > On 13 October 2016 at 17:36, rammohan ganapa
Hi Ramyan,
this is interesting... in our testing (which admittedly didn't cover the
case of this many queues / listeners) we saw the 6.0.x broker using less
CPU on average than the 0.32 broker. I'll have a look this weekend as to
why creating the listeners is slower. On the dequeing, can you giv
The error you get "[con:36(producer11476488793213@/10.16.
16.241:61948/default)/ch:0] CHN-1003
: Close : 404 - Unknown Exchange Type:" is not saying that the exchange has
been deleted, rather that the client has attempted to declare an exchange
but the type of the exchange (e.g. fanout, direct, top
Ram
>
> On Oct 15, 2016 3:02 AM, "Rob Godfrey" wrote:
>
> > The error you get "[con:36(producer11476488793213@/10.16.
> > 16.241:61948/default)/ch:0] CHN-1003
> > : Close : 404 - Unknown Exchange Type:" is not saying that the exchange
> has
> >
ize is 1 and every message is same size
> (200 bytes).
>
> Thanks
> Ramayan
>
> On Sat, Oct 15, 2016 at 2:59 AM, Rob Godfrey
> wrote:
>
> > Hi Ramyan,
> >
> > this is interesting... in our testing (which admittedly didn't cover the
> > case of
our its impact for our usage patterns. Would be very
> helpful if there are more docs/JIRA/email-threads with some details.
>
> Thanks
>
> On Sat, Oct 15, 2016 at 9:21 AM, Rob Godfrey
> wrote:
>
> > So I *think* this is an issue because of the extremely large number of
>
e peer has ceased to function, then I would be more
concerned (albeit in an abstract way as I'm not actually currently using
the API at all :-) ).
-- Rob
On 17 October 2016 at 16:57, Alan Conway wrote:
> On Fri, 2016-09-30 at 14:40 +0100, Rob Godfrey wrote:
> > I don't think it'
OK - that (with the above documentation) seems fine to me - I like the use
of Heartbeat to properly from the notion of the timeout threshold.
-- Rob
On 17 October 2016 at 21:09, Alan Conway wrote:
> On Mon, 2016-10-17 at 17:08 +0100, Rob Godfrey wrote:
> > If this API is not also m
our
> performance tests to validate it.
>
>
I'll make a patch for 6.0.x presently (I've been working on a change
against trunk - the patch will probably have to change a bit to apply to
6.0.x).
Cheers,
Rob
Thanks
> Ramayan
>
> On Sun, Oct 16, 2016 at 3:30 PM, Rob God
On 17 October 2016 at 21:50, Rob Godfrey wrote:
>
>
> On 17 October 2016 at 21:24, Ramayan Tiwari
> wrote:
>
>> Hi Rob,
>>
>> We are certainly interested in testing the "multi queue consumers"
>> behavior
>> with your patch in the new brok
,
> > Helen
> >
> > On Tue, Oct 18, 2016 at 10:40 AM, Ramayan Tiwari <
> ramayan.tiw...@gmail.com
> > > wrote:
> >
> >> Thanks so much Rob, I will test the patch against trunk and will update
> >> you with the outcome.
> >>
> >
+1 from me
Ran 0-9 and 0-10 tests. Ad hoc testing of the management UI.
-- Rob
On 27 October 2016 at 18:17, Keith W wrote:
> +1.
>
> My testing was:
>
> 1) Verified the md5/sha checksums on all distribution artefacts
> 2) Verified signatures on all all distribution artefacts
> 3) Built/ran te
On 31 October 2016 at 16:06, Robbie Gemmell
wrote:
> I don't think there is anything too surprising in what you said, given
> previous discussion and how things have actually progressed over the
> past couple of years.
>
> Messenger is covered upon in your comments, but slightly more in
> relatio
On 31 October 2016 at 17:28, Robbie Gemmell
wrote:
> On 31 October 2016 at 16:37, Rob Godfrey wrote:
> > On 31 October 2016 at 16:06, Robbie Gemmell
> > wrote:
> >
> >> I don't think there is anything too surprising in what you said, given
> >> prev
Hi Akhil,
can you give a little more information about which Broker (C++ / Java),
which client (Java, C+, Python, etc), and which versions of the broker and
client you are using?
Thanks,
Rob
On 2 November 2016 at 08:36, Akhil Samnotra wrote:
> Hi,
>
> We are using Apache qpid as broker between
a and the version we are using is 0.32
> version
>
> Thanks
>
> Akhil Samnotra
>
>
> Sent from my iPhone
>
> > On 02-Nov-2016, at 3:38 PM, Rob Godfrey wrote:
> >
> > Hi Akhil,
> >
> > can you give a little more information about which Broker
patibility issue
>
> Thanks
>
>
> Sent from my iPhone
>
> On 02-Nov-2016, at 5:49 PM, Rob Godfrey wrote:
>
> Which Java client are you using? The Java client for AMQP 0-9/0-10 or the
> Qpid JMS client for AMQP 1.0? Are you using the same client at both the
> sender
Hi Naresh,
Keith responded to your mail three days ago: (see here -
http://mail-archives.apache.org/mod_mbox/qpid-dev/201610.mbox/%
3CCAFEMS4tZgZj1JWrgFGsSdE%2BbW_XSxNk_c%3DRnoHjeP562gQBmyw%40mail.
gmail.com%3E in the list archives).
Can I also suggest that you mail queries of this kind to the us
Hi Nikhil,
which of the JMS clients (AMQP 0-9-/10 or AMQP 1.0) are you using - and
which AMQP broker/service are you connecting to?
Also, queries such as these should probably be send to the
users@qpid.apache.org mailing list where they will likely be spotted easier
than in the dev list which is
d shown you the special characters .
>
>
> Thanks
>
> Akhil Samnotra
>
> Sent from my iPhone
>
> On 02-Nov-2016, at 8:49 PM, Rob Godfrey wrote:
>
> Did you say you are using bytes messages? How are you converting those
> messages into character data? My first th
I guess my question here is what the benefit to sharing a schema is? You
can already have multiple brokers running against the same Oracle
installation as long as they are using different schemas... If they use the
same schema would we be expecting the instances to store their data in the
same tab
ker instance it is
> simpler to connect it to an existing schema and not having to create a
> separate schema. Having said this, I agree that the performance might be
> negatively due to the contention on the shared schema.
>
> Best regards,
> Rawad
>
> -Original Message-
0 November 2016 at 13:09, Rawad Assaf wrote:
> That option would indeed be a solution.
>
> Thanks!
> Rawad
>
> On Wed, Nov 30, 2016 at 1:01 PM, Rob Godfrey
> wrote:
>
> > One option might be to have the store plugin be able to add a prefix to
> the
> > table n
On 30 November 2016 at 15:19, Adel Boutros wrote:
> Hello,
>
>
> Following the discussion regarding the JDBCMessageStore, I would like to
> ask what would happen in the below scenario:
>
>
Bad things :-)
>
> Let's say we have 2 brokers running with the same JDBC message store
> configured (Same
need some
sort of external agent to control which broker (or rather virtual host)
instance should be considered the master.
Cheers,
Rob
>
> Regards,
>
> Adel
>
>
> From: Rob Godfrey
> Sent: Wednesday, November 30, 2016 4:25:31 PM
> To: users
abase to become available to them.
>
> I have previously considered looking to provide some sort of HA-like
> solution based on a RDBMs clustering solution - but you still need some
> sort of external agent to control which broker (or rather virtual host)
> instance should be consider
Just to be clear - the current behaviour of the broker when started with a
BDB VirtualHost*Node* and the BDB jar missing is for the broker to fail to
start. A JSON vitualhostnode with a BDB virtualhost will allow the boker
to start up, but the virtualhostnode will be in the ERROR state.
It would
; I don't mind the broker not starting if a VirtualHostNode is missing jars.
> However, I don't like the fact that a management operation can make a
> running broker fail especially when you have a lot of messages being
> exchanged at the same moment.
>
>
> Regards,
>
Hi Michael,
Which Broker (Java/C++) are you using? Is there anything in the broker
logs indicating an issue at the time where these errors are occurring?
-- Rob
On 1 December 2016 at 17:22, Michael Nachmias
wrote:
> Hello,
>
> I'm running a enterprise Java web application using Java jdk 1.7.0
OK - changed under QPID-7561
<https://issues.apache.org/jira/browse/QPID-7561>
-- Rob
On 1 December 2016 at 17:04, Rob Godfrey wrote:
> Yeah - using the same mechanism as BDB would mean that you wouldn't be
> able to create a Derby vhost / vhostnode if the library wasn&
On Fri, 2 Dec 2016 at 00:01, James Franco wrote:
> yes it is the qpid hello world example . In your statement
>
> "The binding used depends on the topic type (which the client determines by
> asking the broker) and the subject (or other details of the address). Since
> no 'subject' is specified b
Hi Rawad,
I assume you are correct... To be honest I personally don't have a lot of
experience with RDBMs that use schemas - all my serious database work was
against Sybase / SQL Server (and it's probably been 10 years since I was
using them).
When the JDBC store was initially written I fired up
Hi,
unfortunately the mailing list strips attachments from mails - perhaps you
could raise a JIRA here: https://issues.apache.org/jira/browse/QPIDJMS and
attach the files to that?
Thanks in advance,
Rob
On 9 December 2016 at 08:34, Milano Nicolum wrote:
> *Configuration:* Hi, I'm using ActiveM
Obviously the encrypter will have to be in the broker's classpath. If you
use the qpid-server shell script, then it sets the environment variable
QPID_CLASSPATH like so:
QPID_LIBS="${QPID_HOME}/lib/*:${QPID_HOME}/lib/plugins/*:${QPID_HOME}/lib/opt/*"
QPID_CLASSPATH="${QPID_LIBS}"
This is then u
ice loader does?
>
>
> Regards,
>
> Adel
>
> ________
> From: Rob Godfrey
> Sent: Tuesday, December 13, 2016 3:24:17 PM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Java Broker] Providing external encryptor for
> configuration
>
>
It's not that the password cannot be set as a system property, it is that
interpolation (converting ${var} variables into their representation) is
only performed after secret decryption... so if you want your configuration
decrypter to work on values that may be held in system properties, then
your
heir
> representation) is only performed after secret decryption") valid
> indefinitely or might it change in the future?
>
>
> Regards,
>
> Adel
>
>
> From: Rob Godfrey
> Sent: Thursday, December 22, 2016 1:40:49 PM
>
f with the
> >> new broker.
> >>
> >> What is the recommendation for memory allocation (heap vs dm)
> >> in our use case?
> >>
> >> Thanks
> >> Ramaayn
> >>
> >> On Fr
On 6 January 2017 at 14:06, Lorenz Quack wrote:
> 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.A
> bstractJDBCMessageStore#getConnection which is called from multiple
> places.
>
>
To be cl
Hi Antoine,
I'm not sure I'm totally clear on what you mean by "I cannot lose messages"
in this context. Are you saying that if a consumer is connected, then it
should receive all messages which arrive on the "topic" from the point at
which it connects; but once all consumers have seen a message
aves
> now. You can find in blue the answers to your questions below.
>
> Regards,
> Antoine
>
> -----Original Message-
> From: Rob Godfrey [mailto:rob.j.godf...@gmail.com]
> Sent: vendredi 6 janvier 2017 15:52
> To: users@qpid.apache.org
> Subject: Re: Qpid java bro
+1 To removing Java 7 support in the Broker for Java and the JMS client.
On the AMQP 0-x JMS client my inclination is to say that we actually remove
this client from future feature releases. Maintenance releases on the
6.1.x branch will continue to support Java 7 (and 8, of course), but going
for
point might not outweigh the effort
> required.
>
> On 10 January 2017 at 11:05, Rob Godfrey wrote:
> > +1 To removing Java 7 support in the Broker for Java and the JMS client.
> >
> > On the AMQP 0-x JMS client my inclination is to say that we actually
> remove
> >
Splitting out this conversation from the "Ending support for Java 7"
discussion.
Currently the Qpid for Java release contains a Broker and an AMQP 0-x
client. New users should be using the AMQP 1.0 JMS client which is
released as a separate component. The AMQP 0-x client is really in bugfix
mode
Rob
On 11 January 2017 at 19:45, Robbie Gemmell
wrote:
> On 11 January 2017 at 14:39, Rob Godfrey wrote:
> > Splitting out this conversation from the "Ending support for Java 7"
> > discussion.
> >
> > Currently the Qpid for Java release contains a Broker
I must admit that I took Tim's comment (after a moment of reflection) as
meaning "we haven't finalised the timeline for our 1.0 release yet" rather
than "we don't have any plans to ever release to 1.0".
The only potential external pre-condition we might lace on a 1.0 release is
the completion of t
+1
Compiled, ran tests, tested against the Qpid Broker for Java
-- Rob
On 17 January 2017 at 10:49, Gordon Sim wrote:
> 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.
>>
>
>
On 17 January 2017 at 11:37, Adel Boutros wrote:
> Hello,
>
>
> If I understand correctly, you are in a way mapping the JMS release cycle
> to the AMQP support and the JMS specs. So 0.x is still used because support
> form AQM 1.0 is not done yet and when it will be, you will release JMS
> client
On 17 January 2017 at 12:54, Gordon Sim wrote:
> On 17/01/17 10:47, Rob Godfrey wrote:
>
>> I think there are effectively two "public APIs" in place here, the one
>> between the application and the library - which is essentially JMS 2.0,
>> and
>> so
In terms of sending maps/lists I think we said (at OASIS), though it is
possibly not yet in the draft spec, that Json formatted equivalents should
be able to be used for all values... however I have no idea if the Dispatch
Router supports that.
In terms of receiving lists / maps I would assume tha
> On 01/18/2017 07:45 AM, Gordon Sim wrote:
>
>> On 18/01/17 10:45, Rob Godfrey wrote:
>>
>>> In terms of sending maps/lists I think we said (at OASIS), though it is
>>> possibly not yet in the draft spec, that Json formatted equivalents
>>> should
>&
In the Java Broker the definition of "ready" is kind of recursive... it is
ready if all the objects it "manages" are ready... and they are ready if
all the objects they manage are ready... etc.
In practice this means that the when the Broker is ready, all the virtual
hosts have completed recovery
On 20 January 2017 at 21:45, Ganesh Murthy wrote:
>
>
> - Original Message -
> > From: "Robbie Gemmell"
> > To: users@qpid.apache.org
> > Sent: Friday, January 20, 2017 2:18:45 PM
> > Subject: Re: [Qpid Dispatch] Manage Dispatch router from Qpid Jms
> >
> > On 20 January 2017 at 19:06, G
Hi Michael,
the DELAYED_DELIVERY feature will be specified in the upcoming AMQP-JMS
binding which will be a separate document from the core protocol. I am not
sure whether/when Microsoft will be supporting that in Service Bus. All
AMQP 1.0 implementations looking to support JMS 2.0 would be expe
Management protocol at
> any level? If it does, perhaps I could work around it by dropping down to
> AMQP level until official JMS 2.0 support arrives.
>
> Thanks!
>
> On Tue, 24 Jan 2017 at 09:38 Rob Godfrey wrote:
>
> > Hi Michael,
> >
> > the DELAYED_DELI
accept (to ake things easier for JMS users)
-- Rob
On 24 January 2017 at 10:24, Michael Lam wrote:
> Thanks Rob, it helps a bunch. Now the only thing I need to try this out is
> to figure out a not-too-ugly hack to expose the Proton part of Qpid JMS. :)
>
> On Tue, 24 Jan 2017 at 10:16
AMQP 1.0 Management is supported on trunk, and thus will be in the 7.0
release.
There is some incomplete support in earlier versions, but I wouldn't rely
upon it in any way.
-- Rob
On 30 January 2017 at 16:29, Rabih M wrote:
> Hello,
>
> Does the java qpid broker supports Amqp management 1.0 ?
ke it easier
to manage and monitor connected brokers (of any type) connected into a Qpid
Dispatch Router network - for example.
Cheers,
Rob
On 30 January 2017 at 16:38, Rob Godfrey wrote:
> AMQP 1.0 Management is supported on trunk, and thus will be in the 7.0
> release.
>
> There i
I'm not an expert on the JMS client, but I'm not sure that the "verifyHost"
option would make any sense on a non-TLS connection (since by definition
you can only verify the host when you receive the TLS certificate).
I think the use of the Java Broker here is not important, as I assume this
fails
l
> transport'. As you thought, this occurs before it even attempts to
> make a connection.
>
> Robbie
>
> On 1 February 2017 at 10:35, Rob Godfrey wrote:
> > I'm not an expert on the JMS client, but I'm not sure that the
> "verifyHost"
>
Hi Antoine,
what we did in QPID-6906 is make everything consistent, that is if you
don't set the System property / Broker context variable
"broker.failStartupWithErroredChild" to true, then the broker simply logs
the fact that children have been misconfigured or can't open sockets. Prior
to the ch
On 1 February 2017 at 18:37, Robbie Gemmell
wrote:
> If it was considered for back port then it seems a 6.2.0 would be
> better if sticking to a strict semver format, though I wouldn't overly
> mind if it was just included in a 6.1.2 with any intended bugfixes
> either if folks really didn't want
>> producer.send(objectMessage);
> >> ObjectMessage replyMessage = (ObjectMessage)
> responseConsumer.receive(1000);
> >> ...
> >>
> >> I was getting an exception on the .receive() from the dispatch router
> >> saying that the reply-to address is bad
I presume you are referring to the SCRAM-SHA256 authentication provider?
We don't currently have a utility for it, but you could simply take the
code that generates the entries and put it into a standalone program. I
don't know if there are any other tools out there that will also generate
the ha
AbstractScramAuthenticationManager.java (see the method
createStoredPassword(String password) )
-- Rob
On 3 February 2017 at 16:15, Rob Godfrey wrote:
> I presume you are referring to the SCRAM-SHA256 authentication provider?
>
> We don't currently have a utility for it, but you could simply take t
While this does seem like an application concern... I think rolling back
probably makes sense. More generally how are you planning on dealing with
inconsistent state between brokers? What if one of the instances is
temporarily off-line when a new queue is created... or what if you want to
add a n
it's less tolerable
> (broken network).
>
> I thought it was worth checking if someone went down this road before and
> would like to share some experience back.
>
> Thanks,
> Rawad
>
>
>
> On Mon, Feb 6, 2017 at 11:04 AM, Rob Godfrey
> wrote:
>
> >
1 - 100 of 905 matches
Mail list logo
