e same source
code revision.)
So, the connection works now.
Thanks.
- Toralf
On Thu, 24 Nov 2022 at 14:57, Toralf Lund <
<mailto:toralf.l...@pgs.com>
toralf.l...@pgs.com
> wrote:
I'm testing one of our QPid client applications, using the C++ messging API, on
a new ma
I'm testing one of our QPid client applications, using the C++ messging API, on
a new machine. It doesn't work very well, as the attempts to connnect to the
broker fails with exception message
Can't authenticate using ANONYMOUS PLAIN
what does this actually mean? Connections to the same broker
Just got the following from a client application using the C++ Messaging
API:
2021-02-10 07:44:58 [Client] info Trying to connect to
amqp:tcp:192.168.0.215:5672...
2021-02-10 07:44:58 [Network] debug TCPConnector created for 0-10
2021-02-10 07:44:58 [Client] debug Set TCP_NODELAY
2021-02-10 07
On 10/12/2020 22:30, Gordon Sim wrote:
On 10/12/2020 16:04, Toralf Lund wrote:
Where and when exactly are the heartbeats sent?
The interval is negotiated at connection time. I believe the default
for the 0-10 qpid::messaging client is 0, i.e. heartbeats disabled, so
I suspect your client
On 10/12/2020 11:24, Gordon Sim wrote:
On 10/12/2020 09:36, Toralf Lund wrote:
On 09/12/2020 22:55, Gordon Sim wrote:
Does the queue depth on the queue(s) that the slow sends occur on
ever get large? (Is there some limit set on the queue depth?)
The queues are last-value queues sorted on the
On 09/12/2020 22:55, Gordon Sim wrote:
On 09/12/2020 18:36, Toralf Lund wrote:
On 09/12/2020 19:16, Gordon Sim wrote:
On 09/12/2020 13:35, Toralf Lund wrote:
My question is simply, what might cause the send to take several
seconds? I can't see any reason why the communication itself s
On 09/12/2020 19:16, Gordon Sim wrote:
On 09/12/2020 13:35, Toralf Lund wrote:
My question is simply, what might cause the send to take several
seconds? I can't see any reason why the communication itself should
be that slow; the software runs on a machine that's connected to the
sa
We also re-use sessions throughout the application lifetime
OK. Good.
- Toralf
.
On Wed, Dec 9, 2020 at 8:36 AM Toralf Lund wrote:
I'm still debugging the communication issues I've been struggling with
for months - where there are unexpected delays in (I think) message
passi
I'm still debugging the communication issues I've been struggling with
for months - where there are unexpected delays in (I think) message
passing between a C++ Messaging API application and a C++ broker. I've
now narrowed down the problem to the send() call, I believe. I'm using
the following
I'm trying to get back to an old issue with one of our software
installations based the C++ QPid Messaging API with AMPQ 0-10; It's been
discussed here a couple of times before, but unfortunately not a lot has
come out of it.
To make a long story short, I see the following issues in my softwar
In the C++ messaging API, what happens to a Session object when the
"parent" connection is closed? Will for instance hasError() be true?
Will getConnection() return something special? Raise an exception?
Crash? Do something else entirely?
I'm sure I've found out at one point, but I keep forget
On 27/04/2020 10:40, Toralf Lund wrote:
On 22/04/2020 16:24, Gordon Sim wrote:
On 22/04/2020 2:57 pm, Toralf Lund wrote:
On 21/04/2020 22:31, Gordon Sim wrote:
How many of the 'Trying to connect' messages are there and how does
that compare to the number of stale connections?
At
On 22/04/2020 16:24, Gordon Sim wrote:
On 22/04/2020 2:57 pm, Toralf Lund wrote:
On 21/04/2020 22:31, Gordon Sim wrote:
How many of the 'Trying to connect' messages are there and how does
that compare to the number of stale connections?
At the moment there are 39 connections and 5
On 21/04/2020 22:31, Gordon Sim wrote:
On 20/04/2020 12:28 pm, Toralf Lund wrote:
On 16/04/2020 18:00, Gordon Sim wrote:
On 16/04/2020 12:24 pm, Toralf Lund wrote:
It turns out that addition of new connections coincide with log
message like
2020-04-15 09:10:25 [Client] info Trying to
On 16/04/2020 18:00, Gordon Sim wrote:
On 16/04/2020 12:24 pm, Toralf Lund wrote:
Hi,
This is a problem that has been discussed before, but I kind of
reached a dead end in trying to figure out what was going on then, so
I'll try again:
On one particular site where one of our Q
Hi,
This is a problem that has been discussed before, but I kind of reached
a dead end in trying to figure out what was going on then, so I'll try
again:
On one particular site where one of our QPid C++ messaging applications
is used, qpid-stat on the server reports multiple connections wher
On 18/12/2019 12:35, Gordon Sim wrote:
On 18/12/2019 10:42 am, Toralf Lund wrote:
On 18/12/2019 10:40, Gordon Sim wrote:
On 18/12/2019 8:45 am, Toralf Lund wrote:
An additional, more serious issue is that the system has also
locked up a couple of times following an exception during
Sender
On 18/12/2019 12:32, Gordon Sim wrote:
On 18/12/2019 10:42 am, Toralf Lund wrote:
On 18/12/2019 10:40, Gordon Sim wrote:
On 18/12/2019 8:45 am, Toralf Lund wrote:
I don't see any signs of connection errors or explicit reopens but
automatic reconnect with a limit has been enabled
On 18/12/2019 11:30, Gordon Sim wrote:
On 18/12/2019 8:45 am, Toralf Lund wrote:
The application became responsive again after running a debug session
to get the above info.
Using pstack to get the stack traces when it hangs might be useful. It
is less likely to interfere with the running
On 18/12/2019 10:40, Gordon Sim wrote:
On 18/12/2019 8:45 am, Toralf Lund wrote:
On one of our installations of one of our AMQP 0-10 applications
using the QPid messaging API (in C++), we keep getting exceptions
with the message
session-busy: Session detached by peer
- usually while waiting
On one of our installations of one of our AMQP 0-10 applications using
the QPid messaging API (in C++), we keep getting exceptions with the message
session-busy: Session detached by peer
- usually while waiting for incoming messages, but in some cases also
when sending them. After resolving so
Hi.
I didn't notice this answer at first.
On 13/11/2019 16:46, Gordon Sim wrote:
On 12/11/2019 6:35 pm, Toralf Lund wrote:
Good evening, all.
I have an application that uses qpid::Session::nextReceiver() to
handle data from 3 or 4 different AMQP 0-10 message queues - it
follows the pa
Good evening, all.
I have an application that uses qpid::Session::nextReceiver() to handle
data from 3 or 4 different AMQP 0-10 message queues - it follows the
pattern from
https://qpid.apache.org/releases/qpid-cpp-1.39.0/messaging-api/book/ch01s08.html.
Question: If multiple receivers are r
On 11/04/2019 12:53, Gordon Sim wrote:
On 11/04/2019 10:07 am, Toralf Lund wrote:
On 11/04/2019 09:39, Toralf Lund wrote:
On 10/04/2019 18:18, Gordon Sim wrote:
On 10/04/2019 10:10 am, Toralf Lund wrote:
Hi,
In one of my C++ "messaging" programs I sometimes use
qpid::Messagin
On 11/04/2019 09:39, Toralf Lund wrote:
On 10/04/2019 18:18, Gordon Sim wrote:
On 10/04/2019 10:10 am, Toralf Lund wrote:
Hi,
In one of my C++ "messaging" programs I sometimes use
qpid::Messaging::Session::checkError() as a way to "rethrow" (in as
somewhat loose sense
On 10/04/2019 18:18, Gordon Sim wrote:
On 10/04/2019 10:10 am, Toralf Lund wrote:
Hi,
In one of my C++ "messaging" programs I sometimes use
qpid::Messaging::Session::checkError() as a way to "rethrow" (in as
somewhat loose sense) sender or receiver exceptions that
Hi,
In one of my C++ "messaging" programs I sometimes use
qpid::Messaging::Session::checkError() as a way to "rethrow" (in as
somewhat loose sense) sender or receiver exceptions that were already
caught elsewhere. I notice that the exceptions I then get are not quite
the same as the original
On 01/04/2019 22:28, Gordon Sim wrote:
On 29/03/2019 12:26 pm, Toralf Lund wrote:
Another one related to issues I've mentioned in other recent posts:
I'm doing some debugging related to undesired side effects in one of
our applications after it gets a "Failed to connect (reco
broker would
be really hard. Testing has focused on having cruel clients who close
connections and sessions at inopportune moments to test that the broker
survives.
OK.
- Toralf
-Chuck
- Original Message -
From: "Toralf Lund"
To: users@qpid.apache.org
Sent: Friday, March 29
On 03/04/2019 09:32, Gordon Sim wrote:
On 03/04/2019 7:32 am, Toralf Lund wrote:
The broker also has a message saying "Connection ... timed out:
closing". This occurs 4-5 seconds after the session-busy error,
according to the timestamps.
So for some reason, the broker is de
On 01/04/2019 22:33, Gordon Sim wrote:
On 01/04/2019 12:54 pm, Toralf Lund wrote:
On 28/03/2019 15:56, Toralf Lund wrote:
Hi,
I have another question related to my recent post about trying to
re-establish lost connections. Recall that my system is set up
without automatic reconnect, but
On 01/04/2019 22:33, Gordon Sim wrote:
On 01/04/2019 12:54 pm, Toralf Lund wrote:
On 28/03/2019 15:56, Toralf Lund wrote:
Hi,
I have another question related to my recent post about trying to
re-establish lost connections. Recall that my system is set up
without automatic reconnect, but
On 28/03/2019 15:56, Toralf Lund wrote:
Hi,
I have another question related to my recent post about trying to
re-establish lost connections. Recall that my system is set up without
automatic reconnect, but may do a "manual reconnect" via
qpid::Messaging connection(url);
Another one related to issues I've mentioned in other recent posts:
I'm doing some debugging related to undesired side effects in one of our
applications after it gets a "Failed to connect (reconnect disabled)"
error while sending to or receiving from the C++ broker. In then
"manually" reopens
Hi,
I have another question related to my recent post about trying to
re-establish lost connections. Recall that my system is set up without
automatic reconnect, but may do a "manual reconnect" via
qpid::Messaging connection(url);
...
if(!connection.isOpen()) {
connection.open();
On 20/03/2019 10:07, Gordon Sim wrote:
On 20/03/2019 8:02 am, Toralf Lund wrote:
On 19/03/2019 22:07, Gordon Sim wrote:
On 19/03/2019 1:09 pm, Toralf Lund wrote:
Could that fit with what I'm seeing? Is there a chance that
Connection::isOpen() returns false after an error, yet the
conne
On 19/03/2019 22:07, Gordon Sim wrote:
On 19/03/2019 1:09 pm, Toralf Lund wrote:
Could that fit with what I'm seeing? Is there a chance that
Connection::isOpen() returns false after an error, yet the connection
isn't really released? How should I detect and handle that situation?
On 19/03/2019 12:15, Gordon Sim wrote:
On 19/03/2019 9:17 am, Toralf Lund wrote:
Hi,
Is there any way I can find out how many applications or processes
have connected to a certain queue on a qpid cpp broker?
Related question: If I enter "show " for a numeric queue id in
qpid-tool
Hi,
Is there any way I can find out how many applications or processes have
connected to a certain queue on a qpid cpp broker?
Related question: If I enter "show " for a numeric queue id in
qpid-tool, it shows me a "consumerCount" value. What exactly does this
represent? I though it might gi
Hi,
Is there any way to check from a C++ client whether a certain queue has
anything bound do it? Ideally, I'd like to be able to tell a queue
without bindings apart from one that's bound to something, never mind
what it is, but if we have to look for a specific exchange, that might
work, too
On 01/06/16 10:27, Gordon Sim wrote:
On 01/06/16 08:47, Toralf Lund wrote:
Hi,
I haven't had time to look at this again until now...
I restarted qpidd the on the (current) backup server, and after that, I
can't reproduce the issue. I guess this means it was indeed related to
r
n if there is an issue, but I don't really want to disable
it altogether, if you know what I'm saying...
- Toralf
On 26/05/16 18:16, Gordon Sim wrote:
On 25/05/16 13:53, Toralf Lund wrote:
On 24/05/16 16:41, Gordon Sim wrote:
On 24/05/16 15:28, Toralf Lund wrote:
On 24/05/16 13:22, Gor
On 24/05/16 16:41, Gordon Sim wrote:
On 24/05/16 15:28, Toralf Lund wrote:
On 24/05/16 13:22, Gordon Sim wrote:
On 24/05/16 12:20, Gordon Sim wrote:
if you run:
qpid-config queues
and:
qpid-send -q
I think that should allow us to see if there is any queue near its
limit.
qpid-config
On 24/05/16 13:22, Gordon Sim wrote:
On 24/05/16 12:20, Gordon Sim wrote:
On 24/05/16 10:39, Toralf Lund wrote:
Hi,
I have a program that sends messages to a topic exchange using the C++
messaging API. The messages are generally directed to a single receiver
queue. I thought it worked just
Hi,
I have a program that sends messages to a topic exchange using the C++
messaging API. The messages are generally directed to a single receiver
queue. I thought it worked just fine (as always), but now I notice that
it gets stuck a short while after start-up. Simply put, the
sender.send()
On 31/03/16 16:35, Gordon Sim wrote:
On 31/03/16 15:31, Toralf Lund wrote:
The reason why I assumed an exclusive *superscription* was that the
I meant subscription, of course :-)
queue is still there after the application stops. Aren't exclusive
queues supposed to go way automatically?
On 31/03/16 15:05, Gordon Sim wrote:
On 31/03/16 13:27, Toralf Lund wrote:
Hi,
I just encountered an issue related to running one of my QPid
applications in parallel by 3rd party software that receives from the
same queue. I notice that when I start the latter, the queue attributes
as reported
Hi,
I just encountered an issue related to running one of my QPid
applications in parallel by 3rd party software that receives from the
same queue. I notice that when I start the latter, the queue attributes
as reported by qpid-config change from
--durable --replicate=all --lvq-key=qpid.subj
*and*
last-value behaviour, or are these options mutually exclusive?
- Toralf
[http://www.pgs.com/mediaFiles/Exclaimer%20graphics/PGS_LOGO_RGB_42x53px.jpg]<http://www.pgs.com>
Toralf Lund
Senior Software Engineer
Imaging & Engineering | Geoscience & Engineering
Telepho
On 09/02/16 16:51, Gordon Sim wrote:
On 02/09/2016 01:09 PM, Toralf Lund wrote:
I can reproduce the problem every time I try now. The other broker is
using the same QPid version, and I think it's supposed to be set up the
same way. It's managed by someone else (who didn't under
On 09/02/16 12:52, Gordon Sim wrote:
On 02/09/2016 10:37 AM, Toralf Lund wrote:
On 08/02/16 18:07, Gordon Sim wrote:
When enqueing a message, the store attaches its own identifier to it
for use when dequeueing the same message. The error message indicates
that this identifier could not be
On 08/02/16 18:07, Gordon Sim wrote:
On 02/04/2016 08:00 PM, Toralf Lund wrote:
Hi,
I've suddenly started getting exceptions with messages like
framing-error: Queue "": Dequeuing message with null
persistence Id.
(/work/build/build/qpid-0.22/cpp/src/qpid/legacystore/MessageSto
mediaFiles/Exclaimer%20graphics/PGS_LOGO_RGB_42x53px.jpg]<http://www.pgs.com>
Toralf Lund
Senior Software Engineer
Imaging & Engineering | Geoscience & Engineering
Telephone: +47 67 52 64 00
Direct: +47 67 51 57 78
VOIP: 74715778
Mobile: +47 91 31 66 91
Email: toralf.l...@pgs.
On 19/01/16 17:01, Gordon Sim wrote:
On 01/19/2016 02:19 PM, Toralf Lund wrote:
Hi,
I have some questions about the value from
qpid::messaging::Message::getTtl() on received messages; based on
testing, I've concluded that
1. The value returned represents the time that remains of the
.pgs.com>
Toralf Lund
Senior Software Engineer
Imaging & Engineering | Geoscience & Engineering
Telephone: +47 67 52 64 00
Direct: +47 67 51 57 78
VOIP: 74715778
Mobile: +47 91 31 66 91
Email: toralf.l...@pgs.com<mailto:toralf.l...@pgs.com>
A Clearer Image | www.pgs.com<
On 01/12/15 16:38, Gordon Sim wrote:
On 12/01/2015 03:27 PM, Toralf Lund wrote:
I enabled trace via qpid::log::Logger::instance().select(...),
and got log lines containing information like
header (251 bytes); properties={{MessageProperties: content-length=23;
which is tells me most of what I
On 01/12/15 13:52, Gordon Sim wrote:
On 12/01/2015 10:38 AM, Toralf Lund wrote:
Hi,
Is there a simple way to determine the actual size of a certain message,
or alternatively, the size of headers, the QPid "framing" etc., when
using the C++ messaging API?
I'm afraid not
each message...
Thanks,
- Toralf
[http://www.pgs.com/mediaFiles/Exclaimer%20graphics/PGS_LOGO_RGB_42x53px.jpg]<http://www.pgs.com>
Toralf Lund
Senior Software Engineer
Imaging & Engineering | Geoscience & Engineering
Telephone: +47 67 52 64 00
Direct: +47 67 51 57 78
VOIP:
s issue later.
- Toralf
-Chuck
[http://www.pgs.com/mediaFiles/Exclaimer%20graphics/PGS_LOGO_RGB_42x53px.jpg]<http://www.pgs.com>
Toralf Lund
Senior Software Engineer
Imaging & Engineering | Geoscience & Engineering
Telephone: +47 67 52 64 00
Direct: +47 67 51 5
.com/mediaFiles/Exclaimer%20graphics/PGS_LOGO_RGB_42x53px.jpg]<http://www.pgs.com>
Toralf Lund
Senior Software Engineer
Imaging & Engineering | Geoscience & Engineering
Telephone: +47 67 52 64 00
Direct: +47 67 51 57 78
VOIP: 74715778
Mobile: +47 91 31 66 91
Email: toralf
Hi,
I have construct of the form
value=message.getProperties()["property"];
The expected property type is uint32. The value type has up until now
been "unsigned int", so (obviously) the call has worked just fine. But
then I changed it to a double (because I want to use it as a
floating-point
variable name twice
combined with confusion about which one is in scope :-( Once I sort out
this issue, everything works as expected.
- Toralf
On 27/03/15 16:31, Gordon Sim wrote:
On 03/27/2015 03:12 PM, Toralf Lund wrote:
I'm also setting up a temporary receiver with auto-create as a way of
On 27/03/15 15:23, Gordon Sim wrote:
On 03/27/2015 01:40 PM, Toralf Lund wrote:
On 27/03/15 12:41, Gordon Sim wrote:
On 03/27/2015 08:52 AM, Toralf Lund wrote:
Hi,
I'm having problems with the auto-create functionality in the C++
messaging API. Simply put, I pass the following address s
On 27/03/15 12:41, Gordon Sim wrote:
On 03/27/2015 08:52 AM, Toralf Lund wrote:
Hi,
I'm having problems with the auto-create functionality in the C++
messaging API. Simply put, I pass the following address string to
Session::createSender(), hoping to create and connect to an exchange
that
Hi,
I'm having problems with the auto-create functionality in the C++
messaging API. Simply put, I pass the following address string to
Session::createSender(), hoping to create and connect to an exchange
that does not originally exist:
pgs.data; { create: sender, delete: never, node: { typ
On 02/02/15 16:21, Gordon Sim wrote:
On 02/02/2015 03:13 PM, Toralf Lund wrote:
The question is in the subject, really. To elaborate a bit, I'm talking
about receiving AMQP-0.10 messages via qpid::Messaging::receiver in C++.
Am I right to assume that getAvailable() only counts the mes
Hi,
The question is in the subject, really. To elaborate a bit, I'm talking
about receiving AMQP-0.10 messages via qpid::Messaging::receiver in C++.
Am I right to assume that getAvailable() only counts the messages
already in the receiver, meaning that it must have a non-0 capacity for
a mean
On 31/10/14 16:13, Gordon Sim wrote:
On 10/30/2014 01:30 PM, Toralf Lund wrote:
Hi,
We have encountered a problem with an application using QPid 0.22/APQP
0.10 with the C++ messaging API, which could be caused by creation of an
excessive number of threads. This might not be related to QPid
Hi,
We have encountered a problem with an application using QPid 0.22/APQP
0.10 with the C++ messaging API, which could be caused by creation of an
excessive number of threads. This might not be related to QPid, and the
issue may not even be threading in this application (the problem occurs
o
Hi
I'm trying to enable "full" logging in a QPid C++ 0.14 application via
export QPID_LOG_ENABLE="trace+"
but I don't really get a lot of extra information. I'm wondering,
though, if the reason is that I also set up for somewhat more limited
logging in the application, like this:
qpid::
On 29/11/13 14:00, Gordon Sim wrote:
On 11/29/2013 11:17 AM, Toralf Lund wrote:
On 29/11/13 11:19, Gordon Sim wrote:
On 11/29/2013 09:08 AM, Toralf Lund wrote:
One option to reduce the number of distinct senders, and therefore
benefit more from caching, is to use a single a sender per exchange
On 29/11/13 12:48, Bruno Matos wrote:
On 11/29/2013 11:17 AM, Toralf Lund wrote:
On 29/11/13 11:19, Gordon Sim wrote:
On 11/29/2013 09:08 AM, Toralf Lund wrote:
Hi,
Just wondering, what gain is there in reusing Sender objects for
the C++
Messaging API? I mean, over doing something like
On 29/11/13 12:48, Bruno Matos wrote:
On 11/29/2013 11:17 AM, Toralf Lund wrote:
On 29/11/13 11:19, Gordon Sim wrote:
On 11/29/2013 09:08 AM, Toralf Lund wrote:
Hi,
Just wondering, what gain is there in reusing Sender objects for
the C++
Messaging API? I mean, over doing something like
On 29/11/13 11:19, Gordon Sim wrote:
On 11/29/2013 09:08 AM, Toralf Lund wrote:
Hi,
Just wondering, what gain is there in reusing Sender objects for the C++
Messaging API? I mean, over doing something like
qpid::messaging::Sender sender=session.createSender(address);
sender.send(message
Hi,
Just wondering, what gain is there in reusing Sender objects for the C++
Messaging API? I mean, over doing something like
qpid::messaging::Sender sender=session.createSender(address);
sender.send(message);
sender.close();
every time?
I'm thinking about this in conjunction with a request
.
I now vaguely remember reading about this option in the past, but I'd
quite forgotten about it until you mentioned it...
Thanks,
- Toralf
-Steve
-Original Message-
From: Toralf Lund [mailto:toralf.l...@pgs.com]
Sent: Wednesday, November 27, 2013 9:26 AM
To: users@qpid.apac
Hi.
I'm testing pretty standard (I think) request-response type setup for
communication between two processes, using QPid 0.14 (AMQP 0.10).
Messaging is implemented via a the C++ Messaging API, and the broker is
qpidd from qpid-cpp-server. All running under CentOS 6.4. Messages are
typically
On 25/07/12 11:59, Gordon Sim wrote:
On 07/25/2012 08:19 AM, Toralf Lund wrote:
The problem appears to be that I call
qpid::Messaging::session::acknowledge() every time a new message has
been received. If I just comment out this call, I can read all the 1288
messages that are currently sitting
On 25/07/12 09:03, Toralf Lund wrote:
On 23/07/12 16:33, Gordon Sim wrote:
On 07/23/2012 01:58 PM, Toralf Lund wrote:
On 23/07/12 10:42, Gordon Sim wrote:
On 07/23/2012 08:27 AM, Toralf Lund wrote:
Hi.
In my C++ messaging client, I'm reading data from a last-value
queue via
a loop t
On 23/07/12 16:33, Gordon Sim wrote:
On 07/23/2012 01:58 PM, Toralf Lund wrote:
On 23/07/12 10:42, Gordon Sim wrote:
On 07/23/2012 08:27 AM, Toralf Lund wrote:
Hi.
In my C++ messaging client, I'm reading data from a last-value
queue via
a loop that's essentially as follows
On 23/07/12 10:42, Gordon Sim wrote:
On 07/23/2012 08:27 AM, Toralf Lund wrote:
Hi.
In my C++ messaging client, I'm reading data from a last-value queue via
a loop that's essentially as follows:
while(1) {
try
session.sync();
qpid::messaging::Receive
Hi.
In my C++ messaging client, I'm reading data from a last-value queue via
a loop that's essentially as follows:
while(1) {
try
session.sync();
qpid::messaging::Receiver receiver=session.nextReceiver(timeout);
message=receiver.fetch(qpid::messaging::Duration::IMMEDIATE)
On 18/07/12 23:38, Alan Conway wrote:
On Tue, 2012-07-17 at 09:28 +0200, Toralf Lund wrote:
Hi
Does anyone here receive "published" messages in an application using a
something like a GLib main loop? Or Gtk or Qt? If you do, how exactly do
you integrate the message availability chec
On 17/07/12 15:01, Gordon Sim wrote:
On 07/17/2012 11:50 AM, Toralf Lund wrote:
Some more questions loose related to my post on response queues:
1. What's the purpose of qpid::messaging::session::release()? Yeah, it
releases the message, but what precisely does that mean? And how
On 17/07/12 11:52, ghada wrote:
Hello,
I am a debutante in programming the Apache QPID.
I want to achieve a Java program "Publisher/subscriber" that sets up a
publisher and two subscribers sharing the same topic.
I searched in forums for examples but I found nothing.
Can someone help me?
I'm not
Some more questions loose related to my post on response queues:
1. What's the purpose of qpid::messaging::session::release()? Yeah, it
releases the message, but what precisely does that mean? And how
does it affect the state of the receiver?
2. What would be the point of rejecting a messag
iven time will be
higher with queues created on demand. In fact, it may be lower, as
response queues will only exist while clients are waiting for replies.
Thanks,
- Toralf
On Mon, Jul 16, 2012 at 10:45 AM, Toralf Lund wrote:
On 16/07/12 15:01, Rajith Attapattu wrote:
I'd agree wit
Hi
Does anyone here receive "published" messages in an application using a
something like a GLib main loop? Or Gtk or Qt? If you do, how exactly do
you integrate the message availability check with the main loop? I was
hoping there would be filedescriptor that had data available whenever
mess
.
- Toralf
Regards,
Rajith
On Mon, Jul 16, 2012 at 8:39 AM, Gordon Sim wrote:
On 07/16/2012 12:34 PM, Toralf Lund wrote:
Hi.
What kind of overhead to you expect from having to create the
("private") queue when initialising a qpid::messaging::receiver?
If it is not a durable queu
Hi.
What kind of overhead to you expect from having to create the
("private") queue when initialising a qpid::messaging::receiver?
I'm implementing request-response type communication over a direct
exchange, with a private "auto-delete" queue for responses (whose
address is specified in repl
On 13/07/12 12:33, Gordon Sim wrote:
On 07/13/2012 10:34 AM, Toralf Lund wrote:
What happens if I send a message to an exchange without any queues
connected to it? Are they just thrown away? I'm assuming that they are,
and that raises another question: Is there any way I can know if a
mess
On 13/07/12 13:39, Gordon Sim wrote:
On 07/13/2012 12:04 PM, Toralf Lund wrote:
Hi.
I'm wondering if there is any way I can set up options on a
qpid::messaging::Sender so that a direct exchange will be created if
it's missing. I mean, for topic exchanges, I do something like
Hi.
I'm wondering if there is any way I can set up options on a
qpid::messaging::Sender so that a direct exchange will be created if
it's missing. I mean, for topic exchanges, I do something like
sender=session.createSender("myexchange; { create: sender, delete:
never, node: { type: topic
Hi,
What happens if I send a message to an exchange without any queues
connected to it? Are they just thrown away? I'm assuming that they are,
and that raises another question: Is there any way I can know if a
message I just sent reached a queue, without actually checking queues
directly?
-
across the TCP link, since they
can also help detecting a connection problem?
- Toralf
Kind regards,
Pavel
- Original Message -----
From: "Toralf Lund"
To: users@qpid.apache.org
Sent: Wednesday, November 23, 2011 10:53:23 AM
Subject: Re: How to avoid waiting for a very l
Gordon Sim wrote:
On 11/23/2011 09:05 AM, Toralf Lund wrote:
Hello,
Sometimes the host I'm connecting to via qpid::messaging::Connection
turns out to be down. When this is the case, the open() call may exhibit
two different kinds of behaviour, depending on the network configurati
Hello,
Sometimes the host I'm connecting to via qpid::messaging::Connection
turns out to be down. When this is the case, the open() call may exhibit
two different kinds of behaviour, depending on the network configuration
or something:
1. An exception is raised almost immediately, and a me
Note: This is a new message where I've pasted in text from the mailing
list archives rather than a direct reply, as I seem to have stopped
receiving messages to the list again.
On 08/25/2011 01:05 PM, Toralf Lund wrote:
> I'd now like to turn to the "initial value" behav
Hi,
I mentioned this in another message, but I haven't received any messages
to this list the past few days, so I suspect that I've been unsubscribed
although I haven't asked for it myself. Again - this will be the 3rd
time it has happened. I'd appreciate it if someone could try to find out
w
I'd now like to turn to the "initial value" behaviour for exchanges. Can
anyone explain what exactly this means? Is the mechanism documented
anywhere? Obviously, I understand that an exchange with this behaviour
will store some values in addition to forwarding them to queues but what
exactly do
1 - 100 of 114 matches
Mail list logo
