On 2011-05-10 09:25:19, Gordon Sim wrote:
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession.java,
line 1060
https://reviews.apache.org/r/706/diff/1/?file=18458#file18458line1060
What happens here if the address doesn't
:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/701/
---
(Updated 2011-05-10 21:25:11)
Review request for qpid, Alan Conway, Gordon
On 05/12/2011 07:11 PM, Carl Trieloff wrote:
In Exchnage.cpp, we have an ACL check for passive...
why it it there, as all exchange create calls come through declare which
also has the ACL check, any ideas before I delete this code?
On a related point, why does a passive declare require a
On 05/18/2011 04:54 PM, Carl Trieloff wrote:
In working a patch to add ownership to the broker model for ACL, I see
that bindings are the only object we don't use encode and decode. This
meant that the first version of my patch required a change to the
encode/decode of binding in the store
On 05/18/2011 06:33 PM, Carl Trieloff wrote:
On 05/18/2011 12:41 PM, Gordon Sim wrote:
On 05/18/2011 04:54 PM, Carl Trieloff wrote:
In working a patch to add ownership to the broker model for ACL, I see
that bindings are the only object we don't use encode and decode. This
meant
, Andrew Stitcher, Alan Conway, Gordon Sim, and Andy
Goldstein.
Summary
---
QPID-3280: When sending a large number of messages with nonzero TTLs to a
cluster, overall message throughput drops by around 20-30% compared to
messages with TTL 0.
Replaced the complicated message expirly
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/833/#review752
---
On 06/03/2011 07:56 AM, QP_ID wrote:
I install qpid .10 version and python 3.2 seperatly and also new version of
qpid-tools
but while running qpid-confiq command module not found qpid errors
occured. qpidd commands works fine
I want qpid .10 installtion steps and link of complete qpid package
On 06/06/2011 10:10 PM, Robbie Gemmell wrote:
Given that we dont actually link to the 0.8 files on the mirrors from
our download page, and they will still available from the archive area
which is linked for the purpose of getting older releases, I'd say we
should just remove 0.8 from the mirrors
. To reply, visit:
https://reviews.apache.org/r/860/
---
(Updated 2011-06-08 20:31:05)
Review request for qpid, Alan Conway, Gordon Sim, and Kim van der Riet.
Summary
---
Modifies the broker's handling of Message.Accept
request for qpid, Alan Conway, Gordon Sim, and Kim van der Riet.
Summary
---
Modifies the broker's handling of Message.Accept to hold off the completion
of the command until all messages related to the accept have completed
dequeue. This particularly applies to persistent messages
://reviews.apache.org/r/860/
---
(Updated 2011-06-08 20:31:05)
Review request for qpid, Alan Conway, Gordon Sim, and Kim van der Riet.
Summary
---
Modifies the broker's handling of Message.Accept to hold off the completion
of the command
:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/860/
---
(Updated 2011-06-08 20:31:05)
Review request for qpid, Alan Conway, Gordon Sim, and Kim van der Riet.
Summary
---
Modifies
. To reply, visit:
https://reviews.apache.org/r/860/
---
(Updated 2011-06-08 20:31:05)
Review request for qpid, Alan Conway, Gordon Sim, and Kim van der Riet.
Summary
---
Modifies the broker's handling of Message.Accept to hold
:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/860/
---
(Updated 2011-06-08 20:31:05)
Review request for qpid, Alan Conway, Gordon Sim, and Kim
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/882/
---
Review request for qpid.
Summary
---
This patch adds a new method to the
I would like to address QPID-3002[1] in time for the 0.12 release. I
have put a patch up for review[2]. It is pretty low risk as far as I can
see and the functionality requested seems reasonable. It is however
adding a new method to the API so extra review and feedback is appreciated.
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/937/#review876
---
://reviews.apache.org/r/860/
---
(Updated 2011-06-16 15:25:17)
Review request for qpid, Alan Conway, Gordon Sim, and Kim van der Riet.
Summary
---
Modifies the broker's handling of Message.Accept to hold off the completion
On 2011-06-22 15:09:52, rajith attapattu wrote:
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/BasicMessageConsumer_0_10.java,
line 134
https://reviews.apache.org/r/937/diff/1/?file=21364#file21364line134
Agreed. I initially
On 2011-06-22 16:07:41, rajith attapattu wrote:
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/BasicMessageConsumer_0_10.java,
line 134
https://reviews.apache.org/r/937/diff/1/?file=21364#file21364line134
You mean the removal of
On 2011-06-22 16:32:18, rajith attapattu wrote:
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/BasicMessageConsumer_0_10.java,
line 134
https://reviews.apache.org/r/937/diff/1/?file=21364#file21364line134
Yes only the default
On 06/24/2011 04:07 PM, Ken Giusti wrote:
Message Groups
Status
Draft
Summary
This document describes a new feature that would allow a message producer to
enforce the order in which the data from a set of related messages are
processed by consumers.
Problem
While the broker currently
On 06/27/2011 05:25 PM, Robert Godfrey wrote:
So, in general this looks good, and is something we could support in the
Java Broker... My one comment would be that I think the more standard
behaviour for a Group is to ensure all messages in the same group are
delivered (in order) to the same
On 06/27/2011 07:58 PM, Gordon Sim wrote:
For most applications however I believe you can still keep the strict
ordering even allowing for 'requeuing' due to rollback or connection
failure.
Where you want the stronger guarantee that a message is not even
delivered until all preceding messages
On 06/28/2011 09:57 AM, Marnie McCormack wrote:
In JMS, the sequence id would be used to maintain order, but the expectation
is that the group are processed as a whole on receipt of the final message
in the group rather than simply shared out between consumers and processed
in order.
I think
On 06/28/2011 11:56 AM, Alan Conway wrote:
What happens if the consumer dies or cancel's mid-group in this case? Do we
- replay the group from the beginning to another consumer?
- drop the rest of the group?
- continue sending to a new consumer from where the first consumer left
off?
- In which
On 06/28/2011 11:39 AM, Gordon Sim wrote:
So I think the requirements are:
(1) message group must always be processed in order
(2) all messages in a group are processed by the same consumer
(3) the consumer will only complete processing having received the
'final' message in the group
Where
On 06/27/2011 08:19 PM, Kerry Bonin wrote:
I was wondering if there was any existing way to know when a broker failover
occurs (and which broker is active), other then hacking the client?
In a clustered broker you can get notifications of changes to cluster
membership. However other than that
On 06/28/2011 02:34 PM, Ken Giusti wrote:
This is great feedback - thanks to all.
I think the term Message Groups may not be the best term to use as
the name for this feature, as proposed in the qip. I agree that the
term Message Group has historically implied a sticky consumer - at
least
On 06/28/2011 03:31 PM, Alan Conway wrote:
It seems to me that the first mode contains the second: the client can
simply delay acknowledgement of at least one message until it is happy
that the entire group is processed (which could be the entire life of
the consumer, or some shorter span at the
On 06/28/2011 04:10 PM, mick wrote:
On Tue, 2011-06-28 at 15:51 +0100, Gordon Sim wrote:
E.g. imagine the group relates to some real world object being
modelled
and each message contains describes an update
To me that situation seems like it should be modeled as a queue.
Fair point
On 06/28/2011 04:23 PM, Robert Godfrey wrote:
To a certain extent it seem to me that whether it's modelled by multiple
queues or a single queue with groups could be seen as an implementation
detail within the broker... The user knows what they want, and we just need
to provide them with a
On 06/28/2011 04:35 PM, Kerry Bonin wrote:
Irregardless of how it is accomplished, more control is needed over
failover to prevent network splits. The current model is
essentially to accept the broker as a single point of failure, or
deploy Linux clustering.
Without replication or persistence
On 06/29/2011 02:06 PM, Darryl L. Pierce wrote:
In working on the Ruby layer I've hit a serious road block.
For any call that blocks on I/O (Session.synch :block = true) the Ruby
bindings can _not_ wrap that call in a Ruby thread and have it run while
the main application thread continues to
On 06/30/2011 11:55 AM, Alan Conway wrote:
On 06/29/2011 07:43 PM, Darryl L. Pierce wrote:
On Wed, Jun 29, 2011 at 04:58:36PM +0100, Gordon Sim wrote:
...another approach is to ensure that the API being SWIGed supports
non-blocking usage effectively. Though that will take more effort it
seems
On 06/30/2011 03:05 PM, Alan Conway wrote:
I'd like to see something like:
- a thread safe get next event call that returns events for message
delivery, async responses and any other triggers coming from the broker
- a file descriptor that is readable whenever there are qpid events
pending so
On 06/30/2011 03:49 PM, Darryl L. Pierce wrote:
On Thu, Jun 30, 2011 at 03:05:52PM +0100, Alan Conway wrote:
I'd like to see something like:
- a thread safe get next event call that returns events for
message delivery, async responses and any other triggers coming from
the broker
I
On 06/30/2011 05:43 PM, Rajith Attapattu wrote:
Sharing and documenting these props will help ensure that all clients
support it to provide a uniform experience to our end users.
Agreed.
I have collection what I know so far here [1]. If anybody knows about
other props feel free to add it
On 06/30/2011 08:15 PM, Rajith Attapattu wrote:
On Thu, Jun 30, 2011 at 12:59 PM, Gordon Simg...@redhat.com wrote:
On 06/30/2011 05:43 PM, Rajith Attapattu wrote:
Sharing and documenting these props will help ensure that all clients
support it to provide a uniform experience to our end
On 07/01/2011 02:17 PM, Carl Trieloff wrote:
On 06/30/2011 12:50 PM, Gordon Sim wrote:
On 06/30/2011 05:36 PM, Carl Trieloff wrote:
On 06/30/2011 12:21 PM, Gordon Sim wrote:
1) Is it possible for a client to recover the --default-queue-limit
for a
broker?
No, I'm afraid not.
This should
On 07/04/2011 03:39 PM, Rajith Attapattu wrote:
Just to add to it, any changes to the Java client should also be
tested with the cpp test profile.
Any changes to the client failover mechanism should also be tested
with the cpp.cluster profile.
I know it's a pain to run all these profiles,
On 2011-07-07 12:14:51, Gordon Sim wrote:
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/Session.java,
line 1069
https://reviews.apache.org/r/1027/diff/1/?file=22094#file22094line1069
Could you not have used sync() here instead
generated e-mail. To reply, visit:
https://reviews.apache.org/r/1027/
---
(Updated 2011-07-07 02:17:42)
Review request for qpid, Gordon Sim and Robbie Gemmell.
Summary
---
In order to verify the uniqueness of the client ID
On 07/07/2011 06:36 PM, Robert Godfrey wrote:
Is there a way we could do this by using temporary queues and binding
with the client name to an exchange ... I thought that Exchange.Bound
would tell you if there is or isn't any queue already bound with a given
binding key... though the definition
On 06/30/2011 10:39 PM, Justin Ross wrote:
Hi. I created the release branch this morning at revision 1141543.
Some testing revealed a problem in the C++ source distribution, so I
fixed that (with Mick's help) and cut the beta from revision 1141708 on
the release branch. Get it at
On 07/12/2011 01:47 PM, Gordon Sim wrote:
On 07/12/2011 12:18 PM, Robbie Gemmell wrote:
Given that we voted to stop releasing standalone artifacts for the
pure ruby client with the last release, is there any reason to keep it
in the repository?
I noticed that the first thing that happened
On 07/13/2011 04:39 PM, Carl Trieloff wrote:
On 07/13/2011 08:20 AM, Gordon Sim wrote:
Going once, going twice... I'll delete these directories tomorrow AM
unless I hear objections. I'll do so on both the 0.12 release branch
and on trunk.
My only suggestion would be to delete everything
On 07/13/2011 06:16 PM, Carl Trieloff wrote:
How about a top level readme with a where everything is.
Yes, a top level README is reasonable.
I think this is particularly important given the swig bindings as they
are not that easy to find unless you know what you are looking for.
I agree
On 07/14/2011 01:30 AM, Uday77 wrote:
I have a fanout exchange and I am binding different queues to this exchange.
When I send data to this exchange each queue that is bound to this exchange
is getting data as expected. But when I try to connect multiple consumers to
one of these fanned out
On 07/13/2011 07:15 PM, Chuck Rolke wrote:
There already IS a top level README.txt. An edit on that file will go nicely
with the deletion of component directories. Remember to edit the LICENSE and
NOTICE files, too.
Done.
-
On 07/20/2011 04:57 PM, Ken Giusti wrote:
- Original Message -
On 07/01/2011 07:04 AM, Ken Giusti wrote:
For #2:
The key for the header that contains the group identifier would be
provided to
the broker via configuration.
A fixed name like 'qpid.group' seems less likely to confuse.
On 07/25/2011 02:46 PM, Alan Conway wrote:
Response in line
[snip]
Ah, yes - sorry. The lifetime of the group's state depends on the type
of Policy that is being used (see below). For the Sequenced
Consumers policy - which is what I was thinking of in my last reply -
the broker doesn't need to
On 08/04/2011 09:21 AM, et3w503 wrote:
Dear all:
I found a memory leak issue in QPID C++ broker using valgrind.
My qpidd broker is the rpm version from Redhat ftp.
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/RHEMRG/SRPMS/qpidc-0.5.752581-34.el5.src.rpm
Can't say for sure
, Gordon Sim, Steve Huston, Andrew Stitcher, and
Cliff Jansen.
Summary
---
QPID-2643 Building QPID with Visual Studio 2010
This patch changes:
List.h - add a typedef from the original post
IntegerTypes.h - adds 'signed' to int_8 to avoid MSVC complaint
SessionState.cpp, qpid
:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1292/
---
(Updated 2011-08-04 18:28:10)
Review request for qpid and Gordon Sim
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1312/#review1317
---
/branches/qpid-3346/qpid/cpp/src/qpid/broker/DeliveryRecord.cpp
On 08/09/2011 08:10 AM, et3w503 wrote:
Dear all:
My qpidd server crashed because consumer's behavior.
My consumer program(client) always released message if something could not
be done in Subscribe callback.
Are you using the qpid::client API and if so are completions being sent?
What are
On 2011-08-08 10:11:17, Gordon Sim wrote:
/branches/qpid-3346/qpid/cpp/src/qpid/broker/LegacyLVQ.cpp, line 39
https://reviews.apache.org/r/1312/diff/1/?file=30946#file30946line39
The purpose of the check is to ensure that an acquire attempt for a
message that has since been
On 08/09/2011 05:44 PM, Kerry Bonin wrote:
Missed this to reply.
We spin to receive messages, the older API had a callback for a received
message, but we see no equivalent for messaging. There is an asynchronous
fetch, so we have a receiving thread that spins on those. I haven't looked
at the
On 08/09/2011 08:35 PM, Justin Ross wrote:
Howdy, all. The last-minute blocker, QPID-3394, has been fixed, and
there are no open blocker jiras against 0.12. The proposed final RC,
from revision 1154981 of the 0.12 release branch, is available here:
http://people.apache.org/~jross/qpid-0.12/
/
---
(Updated 2011-08-09 22:26:16)
Review request for qpid, Alan Conway, Gordon Sim, Kenneth Giusti, Ted Ross,
Steve Huston, and Cliff Jansen.
Summary
---
This is my proposed code change for C++ and Python to support IPv6
On 2011-08-10 14:15:46, Gordon Sim wrote:
As you have noted the python client doesn't support the AMQP 0-10 defined
url scheme. The c++ messaging API consequently supports the form of url
used by python in addition. That code is in
src/qpid/cpp/amqp_0_10/SimpleUrlParser.cpp and would
On 2011-08-10 14:15:46, Gordon Sim wrote:
As you have noted the python client doesn't support the AMQP 0-10 defined
url scheme. The c++ messaging API consequently supports the form of url
used by python in addition. That code is in
src/qpid/cpp/amqp_0_10/SimpleUrlParser.cpp and would
, Gordon Sim, Kenneth Giusti, Ted Ross,
Steve Huston, and Cliff Jansen.
Summary
---
This is my proposed code change for C++ and Python to support IPv6:
It includes a few different items:
IPv6 support at the socket level
- The C++ broker now listens on both TCPv4 and TCPv6 sockets
On 08/11/2011 01:49 PM, mgoul...@apache.org wrote:
Author: mgoulish
Date: Thu Aug 11 12:49:39 2011
New Revision: 1156604
URL: http://svn.apache.org/viewvc?rev=1156604view=rev
Log:
two new management properties for connections: the sasl mechanism, and the
ssf (security strength factor).
On 08/11/2011 06:40 PM, Andrew Stitcher wrote:
On Thu, 2011-08-11 at 12:27 -0400, Andrew Stitcher wrote:
On Thu, 2011-08-11 at 11:08 -0400, Rajith Attapattu wrote:
...
1. Actually listening/connecting to IPv6 sockets (including the correct
reconnect and multiple listening socket logic)
My
On 08/11/2011 09:03 PM, Andrew Stitcher wrote:
That is correct, you can use an IPv6 socket to accept IPv4 connections
too, but there are good reasons you might want to create separate v4 and
v6 only listening sockets. Essentially this gives you stronger control
over the protocols individually if
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1312/#review1472
---
/branches/qpid-3346/qpid/cpp/src/qpid/broker/DeliveryRecord.cpp
On 2011-08-16 13:56:46, Kenneth Giusti wrote:
/branches/qpid-3346/qpid/cpp/src/qpid/broker/Queue.h, line 419
https://reviews.apache.org/r/1312/diff/2/?file=32699#file32699line419
Agreed - I don't like adding type info here, as it would probably be
abused. You are correct - I
On 2011-08-16 09:08:13, Gordon Sim wrote:
/branches/qpid-3346/qpid/cpp/src/qpid/broker/Queue.cpp, line 122
https://reviews.apache.org/r/1312/diff/2/?file=32700#file32700line122
I don't think match should be part of the MessageAllocator interface. I
think the filter perhaps should
On 08/17/2011 11:01 PM, Alan Conway wrote:
I'm getting a load of unit test failures from unit_tests in make check
from the current trunk: r1158873
There are a load of failures like these:
unknown location(0): fatal error in testSessionManagerSetFlowControl:
std::exception: Connection closed
On 08/18/2011 01:13 PM, Alan Conway wrote:
On 08/18/2011 05:02 AM, Gordon Sim wrote:
On 08/17/2011 11:01 PM, Alan Conway wrote:
I'm getting a load of unit test failures from unit_tests in make check
from the current trunk: r1158873
There are a load of failures like these:
unknown location(0
On 08/17/2011 08:21 PM, Robbie Gemmell wrote:
You say you cant update, but is that really the case? All that is
required to update Ant would be to unpack the ~6+ MB binary (e.g.
from http://www.apache.org/dist/ant/binaries/ ) and add the bin
directory to your path, job done.
In more controlled
On 08/18/2011 01:19 PM, Gordon Sim wrote:
On 08/18/2011 01:13 PM, Alan Conway wrote:
On 08/18/2011 05:02 AM, Gordon Sim wrote:
On 08/17/2011 11:01 PM, Alan Conway wrote:
I'm getting a load of unit test failures from unit_tests in make check
from the current trunk: r1158873
There are a load
On 08/18/2011 02:18 PM, Gordon Sim wrote:
On 08/18/2011 01:19 PM, Gordon Sim wrote:
On 08/18/2011 01:13 PM, Alan Conway wrote:
On 08/18/2011 05:02 AM, Gordon Sim wrote:
On 08/17/2011 11:01 PM, Alan Conway wrote:
I'm getting a load of unit test failures from unit_tests in make check
from
On 08/22/2011 11:16 AM, Keith Wall wrote:
On 18 August 2011 16:14, Gordon Simg...@redhat.com wrote:
On 08/18/2011 04:09 PM, Robbie Gemmell wrote:
The rationale for the change was to add an extension point to the
build system to enable client modules, such as transports and
On 08/22/2011 05:30 PM, tr...@apache.org wrote:
Author: tross
Date: Mon Aug 22 16:30:09 2011
New Revision: 1160325
URL: http://svn.apache.org/viewvc?rev=1160325view=rev
Log:
QPID-3441 - Correct spelling error in C++ broker's QMF schema
Modified:
qpid/trunk/qpid/specs/management-schema.xml
On 08/23/2011 09:35 AM, Robbie Gemmell wrote:
- The C++ broker recently started enforcing that exchange.bind
commands dont use the empty string (though it is throwing the wrong
exception when it does,
https://issues.apache.org/jira/browse/QPID-3443)
That was me (QPID-3363). I was actually
/
---
(Updated 2011-08-24 21:12:24)
Review request for qpid, Gordon Sim and Kenneth Giusti.
Summary
---
QPID-3384: Enable DTX transactions in a cluster.
Functionality appears to work but I'm not happy that its sufficiently tested.
I'd welcome suggestions on what else could be tested
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1690/#review1722
---
/branches/qpid-3346/qpid/cpp/src/qpid/broker/Consumer.h
On 09/02/2011 09:44 PM, Steve Huston wrote:
The new ipv6 test is failing on my nightly cmake build on RHEL 5. This is
the output:
Started IPv6 smoke perftest on broker port 36469
3240.44 1041.88 3372.68 3.29363
Started Federated brokers on ports 43424 45339
Failed: AttributeError - Broker
The broker at present will log warnings about overrunning timer tasks
and late wakeups. Not surprisingly, a common question from users is
whether they should be concerned with these statements and how they
prevent them.
My belief is that in general they can be ignored. The information in the
On 09/07/2011 12:05 AM, Steve Huston wrote:
Federation test also fails (it has for a while, but if this brings
anything to mind I'd like to resolve this one too):
Can't see anything obvious... might conceivably be related to QMF as
well but a lot less obvious if it is. I've checked in a minor
On 09/07/2011 04:46 PM, Andrew Stitcher wrote:
If this is a common issue that users are running into and is confusing
them then demote the messages.
Done.
-
Apache Qpid - AMQP Messaging Implementation
Project:
On 09/12/2011 10:02 PM, Andrew Stitcher wrote:
On Mon, 2011-09-12 at 20:44 +0100, Robbie Gemmell wrote:
Hi all,
As some of you no doubt already know the Java broker has a few
configuration/message store implementations, with there currently
being Memory, Derby (to be split into truly generic
On 09/15/2011 02:13 PM, Andrew MacBean wrote:
All,
I have been looking into the python tests that exist and have come
across tests in 3 separate locations?
qpid/python/qpid/tests/
These are tests of the python client itself (though some of them do
require a broker against which to run).
On 09/15/2011 03:32 PM, Andrew MacBean wrote:
Thanks for that Gordon.
Another question, I am running the python tests against the C++ broker
and get 144 failures - from a total of 469 tests - all saying
'Authentication Failed'.
I am starting the C++ broker with no parameters or config changes
On 09/15/2011 03:41 PM, Gordon Sim wrote:
On 09/15/2011 03:32 PM, Andrew MacBean wrote:
Thanks for that Gordon.
Another question, I am running the python tests against the C++ broker
and get 144 failures - from a total of 469 tests - all saying
'Authentication Failed'.
I am starting the C
:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1980/
---
(Updated 2011-09-20 15:14:26)
Review request for qpid, Alan Conway and Gordon
On 09/22/2011 11:03 AM, raghu132 wrote:
Due to 0 byte messages in the Queue, other messages are not getting processed
and always we need to clear the 0 byte messages, and restarting the Qpid
server.
Can you give a bit more detail? Is this with the c++ or java broker?
What steps have you taken
://reviews.apache.org/r/1980/
---
(Updated 2011-09-22 18:16:08)
Review request for qpid, Alan Conway and Gordon Sim.
Summary
---
This implements QPID-3346. I'd like to get this onto trunk.
This patch does not include
:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1980/
---
(Updated 2011-09-27 20:26:22)
Review request for qpid, Alan Conway and Gordon Sim.
Summary
---
This implements QPID-3346. I'd like to get
MessageChooser
Kenneth Giusti wrote:
A Rose by Any Other Name :)
I had originally thought of calling it MessageSelector... - see below
for my thoughts on the purpose of this class vs Messages class, and why I've
separated the two.
Gordon Sim wrote:
I didn't like
On 09/29/2011 02:45 PM, Cajus Pollmeier wrote:
Hi,
qpid-cpp tests depend on qpid-tools - which are not available inside of the
qpid-cpp distribution.
Yes, though they should be skipped if it is not present.
In turn the tests fail if you use a build service -
which starts from scratch all
/
---
(Updated 2011-10-10 23:14:39)
Review request for qpid, Gordon Sim and Ted Ross.
Summary
---
A slight deviation from the design originally proposed in QPID-3417 - this
change adds the timestamp delivery property to messages using the relatively
simple
On 2011-10-11 07:51:39, Gordon Sim wrote:
/trunk/qpid/specs/management-schema.xml, line 106
https://reviews.apache.org/r/2335/diff/1/?file=49296#file49296line106
I'm torn on this approach to management.
On the one hand I like having a relatively loose schema that can
:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2335/
---
(Updated 2011-10-12 16:15:37)
Review request for qpid, Gordon Sim and Ted
On 10/17/2011 05:39 PM, Robbie Gemmell wrote:
Whether an exchange exists with that name should be irrelevant if
queues are the default. It also certainly isnt what the documentation
says:
The node-type is one of:
topic: in the AMQP 0-10 mapping, a topic node defaults to the
topic
On 10/26/2011 08:38 PM, Carl Trieloff wrote:
Use queue state replication and client failover via the address or
failover exchange.
A few words of warning... as it stands there are a few operational
issues with that 'feature' you should be aware of:
* if links are down replication events can
1 - 100 of 3830 matches
Mail list logo
