Hi,
I have a qpid broker with all exchanges and queues predefined and with ACL
limiting users only to publish messages to specific exchanges and consume
messages from specific queues.
Now I want to write a small client application written in Java using JMS
which should connect to a
Hi,
I had a similar problem with the C++ broker and Java client from release 0.5
(with the Qpid API, JMS API didn't suffered with this problem). I tried to
download the latest source from trunk in SVN repository and compile the
library myself and it solved the problem for me.
Regards
JAkub
the
configuration as I want. Therefore, I prefer finding a solution which
would fit the configuration.
FYI: I was trying this with Qpid 0.5, 0.6 as well as the latest trunk.
The broker is C++ ...
Thanks Regards
Jakub Scholz
the support for addresses somewhere? Do I need
0.7/trunk broker as well or is the 0.7/trunk client sufficient
(currently, I'm running against the latest RedHat MRG broker)?
Thanks Regards
Jakub Scholz
On Wed, Jun 16, 2010 at 18:08, Rajith Attapattu rajit...@gmail.com wrote:
On Tue, Jun 15, 2010
whether it is possible or isn't.
Thanks Regards
Jakub Scholz
On Fri, Jun 25, 2010 at 22:33, Rajith Attapattu rajit...@gmail.com wrote:
Hello Jakub,
I have fixed the fist 3 problems in rev 958102 on qpid trunk.
Many thanks for bringing this to my attention.
Could you also specify the address
be it is correct
like this.
Thanks Regards
Jakub
On Mon, Jun 28, 2010 at 16:14, Rajith Attapattu rajit...@gmail.com wrote:
On Mon, Jun 28, 2010 at 5:25 AM, Jakub Scholz ja...@scholz.cz wrote:
Hi Rajith,
Thanks for the fix - the first three problems are working as expected
with latest trunk. I
session.createConsumer(Destination dest).
But is there any possibility to add subscription keys to this existing
consumer? I can create another consumer, which would subscribe the new
bindings to the same queue, but this solution doesn't seem elegant
enough for me :-o.
Thanks Regards
Jakub Scholz
tried to connect to my broker with the EXTERNAL
authentication. But according to what I found out, the Python client
isn't supporting EXTERNAL authentication. I'm I correct, can someone
confirm it?
Thanks Regards
JAkub Scholz
not really secure the
access to the broker.
How is the EXTERNAL authentication supposed to work? The documentation
describes mainly the PLAIN mechanism and eventually the
KERBEROS/GSSAPI mechanism. But it mentions the EXTERNAL mechanism only
on few occasions ...
Thanks Regards
Jakub Scholz
) in such situation.
Also, it seems to me too complicated from the client perspective.
Therefore I would prefer the approach with peer certificates described
above.
Thanks Regards
Jakub
On Wed, Apr 13, 2011 at 20:03, Gordon Sim g...@redhat.com wrote:
On 04/13/2011 06:59 PM, Jakub Scholz wrote:
Hi
...@redhat.com wrote:
On 04/14/2011 12:46 PM, Gordon Sim wrote:
On 04/13/2011 07:36 PM, Jakub Scholz wrote:
Due to the points above, I would prefer to use a solution, when the
client generates an self signed certificate with the assigned username
in certificate subject and delivers the public key to me
they are not equivalent.
The example did not work as given, but I'm working with it to try to figure
out the right combination of node and link x-declare statements to make it
work.
On Apr 25, 2011, at 1:58 AM, Jakub Scholz wrote:
Hi David,
I believe you are looking for an address similar
Hi,
Based on my experience, I would assume, that if you want your
customers to use RING type queues, you should anyway force it using
ACL, since even when the default policy type is implemented, the
consumer will be probably able to overwrite the default value. You can
use
acl allow Consumer
wrote:
On 04/18/2011 05:23 PM, Gordon Sim wrote:
On 04/14/2011 12:46 PM, Gordon Sim wrote:
On 04/13/2011 07:36 PM, Jakub Scholz wrote:
Due to the points above, I would prefer to use a solution, when the
client generates an self signed certificate with the assigned username
in certificate
Hi,
We are running the Qpid/MRG broker in cluster consisting usually from
2-4 nodes. Our broker configuration contains many persistent queues
(currently several GB, in the future even more). When starting the
cluster (with already existing store), the nodes are being started one
after another.
to find where exactly it times out and I will enter
a JIRA.
Thanks Regards
Jakub
On Thu, Jul 21, 2011 at 16:18, Alan Conway acon...@redhat.com wrote:
On 07/15/2011 11:43 AM, Jakub Scholz wrote:
Hi,
We are running the Qpid/MRG broker in cluster consisting usually from
2-4 nodes. Our broker
There is a reason for this behaviour. Qpidd is run by service startup
scripts and I don't want to block other services from starting until qpidd
has loaded its store. Worse, with cluster-size=N, brokers starting up will
wait till there are N members in the cluster so they can sync their store
Hi Alan,
When the cluster is already running, it shows the ACTIVE state
correctly. But it doesn't work for me (MRG 1.3 ... next week I will be
hopefully able to try it with MRG 2.0 / Qpid 0.10). And I don't think
it can work like that even in newer versions. The state of the cluster
is maybe
Well, it is not perfect method, but if the cluster is not running at
all on the given address, it returns an error almost immediately:
$ qpid-cluster admin/admin@rgc001:28610
Failed: error - (111, 'Connection refused')
Where as if the cluster is JOINING, it gets stuck inside and waits for
some
Hi,
The producer flow control on queues is by default configured to 80% of
the queue size / queue count (that can be changed in the
configuration). The exception are the RING or RING-STRICT queues,
where the default values are not applied.
However, I believe that the default settings do not make
Jakub
On Mon, Sep 5, 2011 at 09:50, Gordon Sim g...@redhat.com wrote:
On 09/04/2011 04:04 PM, Jakub Scholz wrote:
Hi,
I'm using a Java program in following scenario:
1) I have an topic exchange named X
2) I have queue named Y
3) I have a binding routing the messages from exchange X to queue Y
Hi,
We are using following ACL rights for a scenario similar to yours.
acl allow event-consumer create queuename=event-listener-*
acl allow event-consumer delete queuename=event-listener-*
acl allow event-consumer consume queuename=event-listener-*
acl allow event-consumer access
Hi,
The current schema (well, current ... Qpid 0.10 / MRG 2.0) for a queue
seems to handle byteDepth only as uint32:
qpid: schema queue
Object Class: Table Class:
org.apache.qpid.broker:queue:_data(bfd4d378-c6e6-efb6-f0d0-963252cedfaa)
ElementType Access Unit
Destination as the message property and not just the
exchange name and routing key in a plain text.
Thanks Regards
Jakub
On Mon, Sep 5, 2011 at 12:06, Gordon Sim g...@redhat.com wrote:
On 09/05/2011 10:27 AM, Jakub Scholz wrote:
I believe the message contains some property
describing
Hi Gordon,
IMHO it would be great if they can be moved to a lower log level. I
think it is not a correct behaviour when you have warning messages,
but they are nothing to worry about.
Regards
Jakub
On Wed, Sep 7, 2011 at 12:15, Gordon Sim g...@redhat.com wrote:
On 09/06/2011 06:21 PM, Alex
without cman until this issue is fixed. Running it
just with corosync seems to work fine for us.
Regards
Jakub
On Wed, Aug 17, 2011 at 17:38, Jakub Scholz ja...@scholz.cz wrote:
Well, we were trying to go according to the guide, including the
troubleshooting chacklist. But the list seems
Hi,
Today, I found a problem with defining an queue using a very specific
address in JMS API. I have a following address:
response/response_routing_key; { create: receiver, link: { name:
'response_queue', durable: false, x-declare: { auto-delete: false,
exclusive: false, arguments : {
for a
couple of things and I'm pretty sure that I noticed True and False got
encoded as a Boolean whereas true and false get encoded as a String. Pretty
irksome, but that just *may* be your problem??
HTH
Frase
Jakub Scholz wrote:
Hi,
Today, I found a problem with defining an queue using
it and I can connect multiple consumers to
it
Frase
Jakub Scholz wrote:
Hi Fraser,
I was actually trying both, but it doesn't seem to be the problem. The
exclusive flag seemed to be set correctly to false until it reached
the lines mentioned in the initial email.
In Python, it seems
:35, Gordon Sim g...@redhat.com wrote:
On 09/16/2011 02:18 PM, Jakub Scholz wrote:
Hi,
Today, I found a problem with defining an queue using a very specific
address in JMS API. I have a following address:
response/response_routing_key; { create: receiver, link: { name:
'response_queue
On Mon, Sep 19, 2011 at 19:31, Gordon Sim g...@redhat.com wrote:
On 09/19/2011 06:16 PM, Jakub Scholz wrote:
The use case ... is complicated :-). We use the temporary queues in
request-response pattern for responses. We wanted to allow the clients
to connect with several applications using one
it with 0.12? Is someone using it?
I assume the Java and Python clients should work, as they should be
multiplatform. But I'm interested specifically on the C++.
Thanks Regards
Jakub Scholz
-
Apache Qpid - AMQP Messaging Implementation
Hi Praveen,
Have you set the capacity / prefetch for the receivers to one message?
I believe the capacity defines how many messages can be buffered by
the client API in background while you are still processing the first
message. That may cause that both your clients receive 5 messages,
even when
Hi Hamid,
I believe the SSL support in C++ is different on Linux and on Windows.
Assuming you use Linux:
1) export the certificate from Java Keystore to P12 using:
keytool -importkeystore -srckeystore ./keystore_certificate
-destkeystore ./certificate.p12 -deststoretype PKCS12
2) You can
Hi,
The patch is from my colleague. I believe it was probably written for
the version 0.5, maybe 0.6. Unfortunately since we are not building
our own Qpid broker but using the Red Hat MRG versions instead, we
never updated / maintained the patch to work with new versions of
Qpid. Therefore
Hi Hamid,
I'm sorry, I haven't tried SSL on Windows yet.
Regards
Jakub
On Tue, Nov 15, 2011 at 11:22, Hamid.Shahid hamid2...@hotmail.com wrote:
Hi Jakub,
Thank you so much for a detailed reply. I am using Windows environment. Can
you pleaase explain how I can use SSL certificates in windows
Hi,
Regarding the question 2, the connection URL in the JMS API allows you
to specify a broker list with multiple brokers and then reconnect
between them in round robin principle -
http://qpid.apache.org/books/0.12/Programming-In-Apache-Qpid/html/ch03s02.html#section-jms-connection-url
You may
Hi,
Ad 1) It seems that your queue consists from 8 journal files each
~1,5MB big. If 100Kb is your message payload, you have to expect some
overhead, but you can do the math how many messages fit in.
Ad 2) The client can control using acknowledgements and transactions
when are the data really
Hi,
With the patch from JIRA QPID-3175, the Python API should work with SSL
client authentication as well ... it requires Python 2.6 or higher, but
seems tu run almost everywhere. I was using it on Windows, Linux and
Solaris.
Regards
JAkub
Dne 25.1.2012 10:24 pela mpela.ga...@gmail.com
Hi Hamid,
I didn't ... the Python patch I mentioned above is for the pure Python API,
not for the Python wrapper around C++ API.
Regards
JAkub
Dne 25.1.2012 13:54 Hamid.Shahid hamid2...@hotmail.com napsal(a):
Hi Jakub,
Can you please, let me know how you have used the SSL client
Hi Hamid,
The error you get in Chrome is caused by your certificate being loaded
only as a trusted peer on the broker. This is an issue we had with
Java applications - when you use signed certificates, the broker gives
you a list of supported certification authorities and the application
selects
Hi,
I think the last value queues may be helpful for you. It doesn't
change the message content, but it overwrites the older messages with
new messages in the queue based on a configured key. We are using it
for quite a similar scenario - distribution of some prices, where only
the last value for
Hi Davide,
I think for your scenario, the sender should use following address:
amq.topic/instrumet; { node: { type: topic} }
and the receiver may use following address:
ticker; {create:always, node:{type:queue,
x-declare:{arguments:{'qpid.last_value_queue_key':'qpid.subject'} },
x-bindings:[{
Hi,
I played a bit with the support for SSL client authentication in the
C++ API for Windows. It seems that I got it working, at least against
our Red Hat MRG 2.0 (Qpid 0.10) brokers ... I did following changes:
1) Added a support for SASL EXTERNAL mechanism
2) Added new connection option
BTW: The attachment was probably discarded by the mailing list server,
so I uploaded it to http://pastebin.com/gb1RnUYk ... the URL will
hopefully survive :-)
On Wed, Mar 7, 2012 at 00:47, Jakub Scholz ja...@scholz.cz wrote:
Hi,
I played a bit with the support for SSL client authentication
checked and did not see an existing jira for this issue (though it
has been discussed on the mailing list recently), so please go ahead and
open a new jira, and attach your patches to that.
Thanks!
-Steve
-Original Message-
From: Jakub Scholz [mailto:ja...@scholz.cz]
Sent: Wednesday
Hi Hamid,
I understand the advantages of the file based certificates. But:
a) right now I have no idea whether the SChannel API is able to work with them
b) I believe the use of the Windows built in certificate is also in
the other parts of the Windows version (the broker, also client is
already
... I hope it gets committed sooner then my
Python patch for the same feature :-o
Regards
Jakub
On Wed, Mar 7, 2012 at 20:19, Steve Huston shus...@riverace.com wrote:
Ah, ok - thank you very much, Jakub!
-Original Message-
From: Jakub Scholz [mailto:ja...@scholz.cz]
Sent: Wednesday
Hi Paul,
when I opened the QPID-3175 the SSL support didn't worked for me even
in combination with PLAIN SASL mechanism. But some sort of SSL
implementation was already present for the code. So it is possible
that I just didn't configured it correctly. Also, I believe the SSL
support in Python
Hi Rajith,
I was playing with the JMS selectors last week. While they do work and
really select the messages based on the filter, it seemed to me that
it switched off the acknowledgments completely. The Java application
was getting only the selected messages, but I was unable to
acknowledge them
Hi Sumi,
I think the attached code snippet does pretty much what you need using
the JMS API. The reply to address is set as a property to the request
message in the step 6 (to the destination specified in a properties
file). The creation of the temporary response queue and its binding to
the
Hi Paul,
I think right now there is just a first step - support for SSL
EXTERNAL in the Python library. But someone needs to take it to the
next level and include the appropriate support into the tools like
qpid-config, qpid-tool etc.
Regards
Jakub
On Wed, May 16, 2012 at 1:14 AM, Paul Colby
Hi Gordon,
While I agree with you that the flow-to-disk queues have a lot of
problems, I do not think they are totally useless. If you remove them
without any real alternative, you may block the upgrade path for many
people using them. At least speaking for my self, it probably would be
a problem
alternative.
Regards
Jakub
On Fri, Jul 20, 2012 at 11:54 AM, Gordon Sim g...@redhat.com wrote:
On 07/20/2012 10:22 AM, Jakub Scholz wrote:
While I agree with you that the flow-to-disk queues have a lot of
problems, I do not think they are totally useless. If you remove them
without any real
09:31 PM, Jakub Scholz wrote:
We expect the brokers to deliver approximately hundreds of GB of
messages per day. Under normal circumstances, most of the messages
will be consumed by the clients almost immediately, but in some
exceptional situations, they may need to be stored on the broker
point out, flow-2-disk just postpones it at best, in
addition to the fact that it has a serious impact on perf.
While there might be an impact on perf with producer flow control, I'm
sure it's way better than flow-2-disk.
Regards,
Rajith
On Mon, Jul 23, 2012 at 7:40 AM, Jakub Scholz ja
?
Regards
Jakub
On Mon, Jul 23, 2012 at 9:20 PM, Carl Trieloff cctriel...@redhat.com wrote:
On 07/23/2012 07:40 AM, Jakub Scholz wrote:
Yes, the use of flow-to-disk queues unfortunately doesn't solve the
memory issue on 100%. It just decreases the memory consumption, so the
point when the broker
Hi Laurent,
Do you need to use the qpid-config tool? Can't you configure the
exchanges/queues either in the virtualhosts.xml file or using the JMX
Management Console?
Regards
Jakub
On Tue, Aug 21, 2012 at 4:19 PM, laurent.deco...@sungard.com wrote:
Hi Gordon,
Yes, I think I went slightly
sequencetrue/sequence
/exchange
/exchanges
I tried this, and it does not seem to work. Do you know how I could query the
java broker so that I could see what is actually up running ?
-Original Message-
From: Jakub Scholz [mailto:ja...@scholz.cz
Hi Holger,
I cannot answer your question why. But to my understanding the
ExchangeDeclare command with passive=true doesn't really declare the
exchange, but it is just kind of asking whether the exchange exists -
it should return OK in case the exchange exists and FAIL in case
it doesn't.
To
That will be definitely a useful change. It will save us a loot of
rules in our ACL file :-).
Regards
Jakub
On Wed, Aug 22, 2012 at 11:51 AM, Gordon Sim g...@redhat.com wrote:
From 0.18, all that will be required is 'access' permission for the
exchange.
I do not think the # signs are supposed to be used in the ACL rules
for queue names, exchange names or routing keys. I think you have to
use *. Or am I wrong?
Apart from that I'm not sure what is the binding URL you are using
actually supposed to do. Is there some reason why are you using the
old
I think there are some misleading bugs in the docu ...
The Qpid 0.16 docu, in chapter 1.5.2.3. uses as example:
acl allow guest@QPID bind exchange name=amq.topic routingkey=stocks.rht.#
(The same is also in MRG-M 2.1 docu chapter 11.2.3.)
Also the cwiki page you linked to seems to contain
Please be aware that - unless something changed in the last releases
since Qpid 0.14 / MRG-M 2.1 - the sequencing in C++ broker doesn't
ensure unique numbers. The problem I found when investigating this
functionality is that the sequence is restarted when the broker is
restarted and starts from 1
T.* will work for all T.1, T.2, T.1.1, T.2.1.3 ... i.e. it will work
as T.# and not as T.* :-o
Regards
Jakub
On Wed, Aug 22, 2012 at 5:45 PM, holger holger.cae...@credit-suisse.com wrote:
Refering to what Chug said. I understand there's no # in ACLs. Now I want
to emulate T.# with the help of
Can you try to run the client with the SSL debug mode? (option
-Djavax.net.debug=ssl ...
http://docs.oracle.com/javase/1.5.0/docs/guide/security/jsse/ReadDebug.html)
I'm usually using this SSL debug mode with our customers when they
have SSL problems. It sometimes shows bit more details why the
Hi Peter,
You do not have the private key properly loaded with the rest of the
certificate in your database. The database listing looks like this
with a private key properly loaded:
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
cbgc03
Hi Gordon,
The concept in QPID-4339 looks nice. Thanks for your work invested into it.
For our use of Qpid, the priority queues and LVQ are not an issue. You
do not mention browsing or simultaneous access to the queue by
multiple receivers, but from the detailed description I assume that
this
Hi Hamid,
I think it is up to date. The QPID-3914 JIRA is not part of trunk, so
unless some other JIRA delivered the SASL EXTERNAL support, the trunk
doesn't support it.
Regards
Jakub
Dne 24.10.2012 10:57 Hamid.Shahid hamid2...@hotmail.com napsal(a):
Hi Steve,
Is this link up-to-date?
Its
Hi Hamid,
Yes, we wrote the patch because of the SSL client authentication. It worked
in our tests and we have some customers which we pointed to it and I assume
they are using it.
Regards
Jakub
Dne 29.10.2012 15:32 Hamid.Shahid hamid.sha...@sungard.com napsal(a):
Hi Jackob,
Thank you for
Hi Marcello,
Honestly, I'm not really a Windows developer - when working on the patch,
the certificate system on Windows seemed to me incredibly chaotic -
especially compared to Java or to the Qpid C++ client on Linux :-(. I also
experienced some issues with finding the proper certificate store.
Hi Marcello,
Sorry, I meant another store. One more idea ... since you used the
ssl-client-auth-filecert.path version of the patch, you should be able to
point the application to the certificates stored in a files. Have you tried
whether that helps to solve the problem?
Regards
Jakub
On Thu,
Hi Andrew,
It is not clear to me from your proposal whether I can specify multiple
interfaces to listen on. Can I pass multiple interface=... options in the
config file in the same way I can use multiple log-level=... options?
Also I think it would be great if I can distinguish between SSL and
Hi Matjaz,
Here is a simple message receiver which might inspire you:
http://pastebin.com/CEXP8dzu ... (I'm not saying this is the best / perfect
solution ... but it may work for you...).
Regards
Jakub
On Tue, Nov 13, 2012 at 9:09 PM, Matjaž Ostroveršnik
matjaz.ostrovers...@halcom.si wrote:
:5671 at the same time.
Regards
Jakub
On Wed, Nov 14, 2012 at 4:51 AM, Andrew Stitcher astitc...@redhat.comwrote:
On Wed, 2012-11-14 at 00:00 +0100, Jakub Scholz wrote:
Hi Andrew,
It is not clear to me from your proposal whether I can specify multiple
interfaces to listen on. Can I pass
security level.
Did this answered your question?
Regards
Jakub
On Wed, Nov 14, 2012 at 3:39 PM, Andrew Stitcher astitc...@redhat.comwrote:
On Wed, 2012-11-14 at 00:00 +0100, Jakub Scholz wrote:
...
For example on some of our brokers we have one
network interface which connects the broker
Hi Adam,
What version of the broker are you using? It seems to me that this example
is based on the old deprecated qpid.client API. The chapter 1.6 of the
manual for Qpid 0.18 seems to contain an example based on the
qpid.messaging API ...
Hi Matjaž,
ad Q1) I believe that the message has an property user-id which is assigned
to the message by the client application and verified by the broker when it
receives the message. If the user-id doesn't match the user-id of the
authenticated user (i.e. the sender), the broker will throw an
18, 2012 at 3:01 AM, Jakub Scholz ja...@scholz.cz wrote:
Hi Lance,
From the client you can use address similar to this to create and
temporary
ring type queue:
queue_1;
{
create: receiver,
assert: never,
node:
{
type: queue,
x-declare
Hi Ted,
From my experience I have to agree with you, that the way the
request/response is handled in the current API is a bit complicated and
caused some troubles to some of our customers connecting to our brokers.
But at the same time I like the flexibility of the current approach, where
you
Hi,
My colleagues were seeing similar errors when using the MRG-M 2.1 broker:
2012-10-05 10:13:10 error Unexpected exception: Attempted count underflow
on dequeue(313): size: max=100, current=243; count: max=1000,
current=0; type=flow_to_disk (qpid/broker/QueuePolicy.cpp:50)
2012-09-27
Hi,
I played a bit with the SSL Client Authentication which is supported in the
last versions of the Java Broker. It seems to work fine, but there are some
differences compared to the implementation in the C++ broker.
The C++ broker implementation is based on the NSS library from Mozilla. The
Hi Aleš,
I think you can use the --argument=NAME=VALUE option of the qpid-config
to specify the number of priorities. It is a long time since I used it, but
I believe it should be something like ...
--argument=qpid.priorities=10
... to specify that you want the queue to distinguish 10 priority
attributes to the Broker configured object to allow the
configuring of peerstore.
Kind Regards,
Alex
On 27 February 2013 14:11, Jakub Scholz ja...@scholz.cz wrote:
Hi,
I played a bit with the SSL Client Authentication which is supported in
the
last versions of the Java Broker. It seems
Hi Rob,
On Wed, Feb 27, 2013 at 3:34 PM, Rob Godfrey rob.j.godf...@gmail.comwrote:
At first read that all sounds sensible - looking forward to seeing the
patch.
Great ... as I mentioned in my answer to Alex, we have just a rough
prototype right now ... we will need a bit more time to add
I was trying it only with python on my MRG-M 2.2 / Qpid 0.14 broker and it
worked fine. Maybe something changed between 0.14 and 0.18.
I created the queue like this:
qpid-config -a admin/admin@rgc001:21313 add queue testP
--argument=qpid.priorities=10
and afterwards tested it with following
It might not be related to your problem, but I think it doesn't make sense
to use limit-policy=ring and at the same time max-queue-size=0 and
max-queue-count=0 ... to make the ring type policy work, you need to limit
the queue size.
Jakub
On Mon, Mar 4, 2013 at 11:18 AM, Rajesh Khan
If you are still using the XML configuration, in the virtualhosts.xml you
should be able to add the binding in the queue section ... like this:
queue
namequeue1/name
queue1
exchangeexchange1/exchange
Hi,
I noticed that the QueueQuery and ExchangeQuery commands (AMQP 0.10) are
not exactly protected using the ACL rules on the Java broker. Once the user
is allowed to access the virtual host in the ACLs, he seems to be able to
send the QueueQuery and ExchangeQuery requests and receive the
I created a JIRA QPID-4676 (https://issues.apache.org/jira/browse/QPID-4676)
covering the second issue with the way the usernames are being created.
Thanks Regards
Jakub
On Thu, Feb 28, 2013 at 12:22 AM, Jakub Scholz ja...@scholz.cz wrote:
s, that might be an option as well. I remember
Hi Bruno,
I do not think there is such option on the C++ broker right now. When we
needed to achieve something similar with our brokers, we used following
workaround ...
1) We configured the broker to use one port for PLAIN connections and
another one for SSL
2) We restricted the SSL port to use
Hi Justin,
First of all, the new website looks much better then the current one - it
has much more modern and elegant look. It will definitely leave a lot
better first impression on new visitors :-). Thanks for the good job. But I
still have some points which can be IMHO improved (from my
Hi Ken,
I don't know about the Qpid 0.18 release, but he might be using MRG-M 2.3
which reports it self as Qpid 0.18 and contains the SSL support in
qpid-config.
Regards
Jakub
On Wed, Apr 10, 2013 at 5:07 PM, Ken Giusti kgiu...@redhat.com wrote:
Hi D James,
I'm pretty sure the ssl options
From a user point of view ... if the client libraries have independent
releases, it might be more clear to many people that they do not need to
use exactly the same version of the client library as is the broker
version. That seems to be quite popular believe among the people connecting
to our
My impression right now is that while the broker has some sort of modular
design, the interfaces are not really advertised / published (correct me if
I'm wrong). So maybe the discussion can be taken a step further and focus
on whether it is intended to have the plugin interfaces published,
Hi Rajib,
Do you use producer flow control on your queues? This exception:
javax.jms.JMSException: Exception when sending message:timed out waiting
for completion
at
org.apache.qpid.client.BasicMessageProducer_0_10.sendMessage(BasicMessageProducer_0_10.java:243)
at
Hi all,
This issue doesn't seem to be so complicated to reproduce. I used a
following scenario:
1) Create a large queue on a broker (C++ / Linux)
2) Start feeding messages into the queue using C++/Linux program (in my
case I used approximately 1kB messages)
3) Connect with a receiver
Hi,
I think the Python is needed only at the build time for generating some
parts of the code. I do not think you need it at runtime.
Regards
Jakub
On Thu, Aug 1, 2013 at 1:24 PM, yonexw zw...@liquidcapital.com wrote:
Hi All,
I am trying to build qpid C++ client apid, when I configure it I
One more update from my side ... I finally managed to build the 0.22
release. The problem is fully reproducible there as well. However, I tried
to increase the BufferCount value in AsynchIO.h from 4 to 5 and that seems
to solve the problem - at least in the terms that the error doesn't
reproduce
Hi Hamid,
I'm sorry, I do not really know the idea behind the buffers. Steve
mentioned the possibility of increasing the buffer count. From the code
where the exception is created it is apparent that there is additional
buffer missing, but I do not really know how the SSL data are decrypted and
1 - 100 of 342 matches
Mail list logo
