+1
Rajith
On Wed, May 11, 2011 at 7:26 AM, Robbie Gemmell
robbie.gemm...@gmail.com wrote:
Hi all,
I'd like to get a mailing list set up to direct to from the CI tasks
that Andrew Kennedy has set up Jenkins/Hudson. After looking through
the mail archives, the ASF naming convention for this
Sorry I couldn't fine anything in Exchange.cpp
Could you pls point me to it ?
Regards,
Rajith
On Thu, May 12, 2011 at 2:11 PM, Carl Trieloff cctriel...@redhat.com wrote:
In Exchnage.cpp, we have an ACL check for passive...
why it it there, as all exchange create calls come through declare
Welcome and well deserved !
Yours is a good example that writing code is not the only criteria for
being elected a committer.
It's nice to see the effort you put into the release and your
leadership around this area is well recognized and appreciated.
Rajith
On Thu, May 19, 2011 at 5:59 PM,
Folks,
I am trying to tidy up the error handling code in the JMS client and
is soliciting ideas and feedback.
I also have rough proposal outlined below.
Please feel free to make suggestions/improvements for the following
solution or any alternative ideas that you might think maybe better.
at the connection level and those which should be handled at the
session level (or even somewhere down the line).
Another concern in this case is the use of failover mutext as per [1].
[1] - https://issues.apache.org/jira/browse/QPID-3259
Danushka
On Wed, May 25, 2011 at 1:47 AM, Rajith
will create a JIRA and post a patch for the above proposal.
Regards,
Rajith
On Tue, May 24, 2011 at 4:17 PM, Rajith Attapattu rajit...@gmail.com wrote:
Folks,
I am trying to tidy up the error handling code in the JMS client and
is soliciting ideas and feedback.
I also have rough proposal outlined
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/833/
---
Review request for qpid.
Summary
---
As mentioned in the JIRA a simple
Justin,
Wondering if you could move the beta date to 17th of June (friday) instead
of the 15th?
Regards,
Rajith
On Tue, May 31, 2011 at 5:19 PM, Justin Ross jr...@redhat.com wrote:
Hi, folks. Here are some of the upcoming dates for the 0.12 release
of Qpid.
- 3 March - 0.12 trunk opened
to rethink
this section.
- rajith
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/833/#review752
---
On 2011-06-02 02:52:57, rajith attapattu
I think we had a good discussion on this thread and some ideas/plans were
floated/discussed.
I am wondering where we are at in terms of the 1.0 plans ?
Maybe it's a good time to restart the discussion to get some ideas about
timelines or share any work that has been done in this area.
Rajith
On
easily.
- Aidan
On Thu, Jun 2, 2011 at 2:21 PM, Rajith Attapattu rajit...@gmail.com wrote:
Justin,
Wondering if you could move the beta date to 17th of June (friday) instead
of the 15th?
Regards,
Rajith
On Tue, May 31, 2011 at 5:19 PM, Justin Ross jr...@redhat.com wrote
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/937/
---
Review request for qpid.
Summary
---
The patch makes the following changes
I have created to QPID-3317 to take care of this.
- rajith
On 2011-06-20 17:29:56, rajith attapattu wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/937
consumers use a destination with a named link will get an
error as it will be trying to create a subscription on a private queue.
Note subscription queues created based on link props are marked exclusive
even if it's overridden using x-declare.
- rajith
On 2011-06-20 17:29:56, rajith
On Thu, Jun 30, 2011 at 10:38 AM, Justin Ross jr...@redhat.com wrote:
Good idea. I'll use that for the upcoming version number changes.
Nice !
Justin
On Thu, 30 Jun 2011, Rajith Attapattu wrote:
This is just an idea. Instead of using NO-JIRA we could create a JIRA
for 0.12 and then use
We currently have several Qpid specific props for retrieving
information from messages.
They provide a nice extension point to retrieve various information
that is otherwise not exposed in standard methods.
For example, with the JMS client, some folks would like to retrieve
the routing-key the
to recognize them and add references accordingly.
It doesn't hurt to have record of what exactly was ported into the
release branch.
Rajith
Robbie
On 30 June 2011 15:25, Rajith Attapattu rajit...@gmail.com wrote:
This is just an idea. Instead of using NO-JIRA we could create a JIRA
for 0.12
On Thu, Jun 30, 2011 at 12:59 PM, Gordon Sim g...@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 users.
Agreed.
I have collection what I know so
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, especially considering
each run takes about 30-40 mins.
.
Robbie
On 4 July 2011 15:39, Rajith Attapattu rajit...@gmail.com 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
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1027/
---
Review request for qpid, Gordon Sim and Robbie Gemmell.
Summary
---
In
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1027/#review985
---
On 2011-07-07 02:17:42, rajith attapattu wrote:
---
This is an automatically generated
of a new method?
rajith attapattu wrote:
I did wonder about this myself. But once a session is detached you can no
longer sync on it right (from the broker side) ? (Bcos you need a valid
session to sync on).
Besides when the session is detached it's marked close on the client
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1027/#review989
---
On 2011-07-07 02:17:42, rajith attapattu wrote:
---
This is an automatically
-mail. To reply, visit:
https://reviews.apache.org/r/1027/#review989
---
On 2011-07-07 02:17:42, rajith attapattu wrote:
---
This is an automatically generated e-mail. To reply, visit
of a new method?
rajith attapattu wrote:
I did wonder about this myself. But once a session is detached you can no
longer sync on it right (from the broker side) ? (Bcos you need a valid
session to sync on).
Besides when the session is detached it's marked close on the client
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1087/#review1041
---
On 2011-07-13 04:04:38, rajith attapattu wrote:
/trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/network/Transport.java,
line 30
https://reviews.apache.org/r/1087/diff/1/?file=22375#file22375line30
Looking at the Transport class, I see that transports are choosen
Justin,
Could we apply the fix for QPID-3302 into the release branch ?
It's a very low impact change and it allows folks to use JMS to do QMF
operations via Map messages.
Regards,
Rajith
On Tue, Jul 12, 2011 at 1:31 PM, Chuck Rolke cro...@redhat.com wrote:
+1 Ship it.
-Chuck
-
guess I got confused with the alpha release. I believe this was
after the alpha, but forgot that you didn't branch until after that.
Again please accept my apologies !
Rajith
Justin
- Original Message -
From: Rajith Attapattu rajit...@gmail.com
To: dev@qpid.apache.org
Sent: Thursday
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 Thu, Aug 11, 2011 at 10:59 AM, Andrew Stitcher astitc...@redhat.com wrote:
I've been spending much of my time in the past few weeks getting support
for IPv6 in to the C++ and python code bases, and I expect to get it in
the code base in the next few days (unless someone can see a problem not
We had a contributor who did build ubuntu packages for Qpid.
However I am not sure about the current status and a bit of googling
found the following link
http://ubuntuforums.org/showthread.php?t=1785914
From searching the mailing lists for the contributor of ubuntu
packages I found Mike Owens.
Welcome Keith !
Regards,
Rajith
On Wed, Aug 17, 2011 at 3:22 PM, Robbie Gemmell
robbie.gemm...@gmail.com wrote:
Welcome, Keith :)
Robbie
On 17 August 2011 18:22, Carl Trieloff cctriel...@redhat.com wrote:
Keith has been nominated and voted onto Qpid as a committer and has
accepted.
://reviews.apache.org/r/1608/
---
(Updated 2011-08-22 08:58:27)
Review request for qpid and rajith attapattu.
Summary
---
This patch changes the 0-10 code path to create the SASL callback handler
using the CallbackHandlerRegistry
The issues highlighted by Robbie are pretty much the problem areas
that I have identified as well (along with a few more).
All in all the failover code is the Achilles heel in the JMS client
and most of the stability issues, deadlocks and race conditions are
around this area.
I've been collecting
)
Review request for qpid and rajith attapattu.
Summary
---
This patch changes the 0-10 code path to create the SASL callback handler
using the CallbackHandlerRegistry. This allows the 0-10 code path to
support SASL mechanisms requiring other callback handlers, such as
CRAM-MD5-HASHED
Thanks for posting the write up.
Comments inline.
On Fri, Sep 16, 2011 at 12:26 PM, Oleksandr Rudyy oru...@gmail.com wrote:
Hi all,
Me and Robbie created the following draft of Failover Policy for Qpid
Java Client.
Could you please comment on it?
Qpid Java Client Failover Policy
1. Qpid
Hi Keith,
The system properties are documented here
http://qpid.apache.org/books/0.12/Programming-In-Apache-Qpid/html/ch03s06.html
It would be nice if you can add them here as well. These docs are version
controlled and is released along with the code/binaries.
So if you are planning any
On Thu, Sep 22, 2011 at 12:19 PM, Oleksandr Rudyy oru...@gmail.com wrote:
Thanks Rajith for your commentaries.
I have discussed them with Robbie, our comments inline.
Qpid Java Client Failover Policy
1. Qpid client failover basic principles.
On Thu, Sep 29, 2011 at 12:02 PM, Oleksandr Rudyy oru...@gmail.com wrote:
Rajith,
Thanks a lot for your feedback.
Could you also have a look into the Failover Behaviour WIKI we created
to summarize the failover behaviour?
Alex nice work to get the wiki page up and running.
I added my
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2366/
---
Review request for qpid, Gordon Sim, Robbie Gemmell, Weston Price, and Keith
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2364/
---
(Updated 2011-10-12 21:09:40.553855)
Review request for qpid, Gordon Sim,
---
On 2011-10-12 21:09:40, rajith attapattu wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2364
of mutating operations we currently have in our
Destination implementations is rather incorrect (and also creates scope for
thread safety issues).
rajith attapattu wrote:
First up, thanks for taking the time to look at the patches. I appreciate
it.
As for the testing situation I
of mutating operations we currently have in our
Destination implementations is rather incorrect (and also creates scope for
thread safety issues).
rajith attapattu wrote:
First up, thanks for taking the time to look at the patches. I appreciate
it.
As for the testing situation I
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2364/#review2584
---
On 2011-10-12 21:09:40, rajith attapattu wrote
generated e-mail. To reply, visit:
https://reviews.apache.org/r/2366/#review2549
---
On 2011-10-12 21:02:31, rajith attapattu wrote:
---
This is an automatically generated e-mail. To reply
:
https://reviews.apache.org/r/2366/#review2551
---
On 2011-10-12 21:02:31, rajith attapattu wrote:
---
This is an automatically generated e-mail. To reply, visit:
https
-mail. To reply, visit:
https://reviews.apache.org/r/2366/#review2589
---
On 2011-10-12 21:02:31, rajith attapattu wrote:
---
This is an automatically generated e-mail. To reply
On Mon, Oct 17, 2011 at 5:54 AM, Robbie Gemmell
robbie.gemm...@gmail.com wrote:
Why do we resolve Address node types? This question arose during
review of proposed updates to the Address syntax implementation for
the Java client, but ultimately looks to be a wider question for all
the clients
On Mon, Oct 17, 2011 at 12:39 PM, Robbie Gemmell
robbie.gemm...@gmail.com wrote:
On 17 October 2011 16:01, Rajith Attapattu rajit...@gmail.com wrote:
On Mon, Oct 17, 2011 at 5:54 AM, Robbie Gemmell
robbie.gemm...@gmail.com wrote:
Why do we resolve Address node types? This question arose during
that everybody feels is appropriate
and desirable.
Rajith
Cheers,
Rob
On 17 October 2011 23:09, Robbie Gemmell robbie.gemm...@gmail.com wrote:
On 17 October 2011 20:58, Rajith Attapattu rajit...@gmail.com wrote:
On Mon, Oct 17, 2011 at 12:39 PM, Robbie Gemmell
robbie.gemm...@gmail.com wrote:
On 17
On Thu, Oct 20, 2011 at 12:38 PM, Robbie Gemmell
robbie.gemm...@gmail.com wrote:
On 20 October 2011 16:36, Rajith Attapattu rajit...@gmail.com wrote:
On Thu, Oct 20, 2011 at 6:05 AM, Rob Godfrey rob.j.godf...@gmail.com wrote:
Sorry for being a little late responding to this thread...
Stepping
On Mon, Oct 31, 2011 at 9:18 AM, Robbie Gemmell
robbie.gemm...@gmail.com wrote:
Hi all,
Over the weekend I made a change to the 0-10 Java client so that using
prefetch=1 with transacted sessions and an OnMessage() listener would
result in the client only getting 1 message at a time, by moving
really makes any difference to asynchronous consumers.
I'm fine with the current change you've made.
Lets actually look at this credit issue in more detail after the release.
Robbie
On 31 October 2011 15:19, Rajith Attapattu rajit...@gmail.com wrote:
On Mon, Oct 31, 2011 at 9:18 AM, Robbie
Hi All,
Pavel has raised QPID-3575, where connections are not being closed
properly when session exceptions are raised via exception listeners.
He has also observed that, explicit closing of the session (after
receiving the exception) as a workaround doesn't work either.
We should investigate
Hi Robbie (and co),
I noticed at least one behavioural changes that warrants a prominent
release note.
I've added a comment in QPID-3583 to cover the change of acking
behaviour for the AUTO_ACK case. See [1]
Could you guys help with some of the changes made in the failover side.
I'd let you
TCP_NODELAY makes a considerable improvement in synchronous cases
(sync pub, sync ack etc) and small tx cases and we generally recommend
that as a tuning option to our users/customers.
The reason for making TCP_NODELAY false by default is based on the
assumption that in most cases people will
The upcoming java client work will have this mind (in fact a requirement).
The core client will have minimum (if not any) dependencies to
facilitate mobile environments.
We expect to do something in the 0.16 (release) time frame, if not
0.18 for sure.
(We are currently about to release 0.14 and
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2832/
---
Review request for qpid, Gordon Sim, Robbie Gemmell, Weston Price, and
Oleksandr
for an explanation for why this is needed.
- rajith
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2832/#review3264
---
On 2011-11-15 15:36:36, rajith
as part of the block here? If so are
there any lock ordering issues where you could be introducing a deadlock?
rajith attapattu wrote:
Not that I could think of. The message-delivery-lock is taken to ensure
that no messages are being served while we start pulling them out of the
queue
do the
final commit :)
- rajith
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2832/#review3294
---
On 2011-11-15 15:36:36, rajith
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2853/
---
Review request for qpid, Gordon Sim, Robbie Gemmell, Weston Price, Keith Wall,
of AMQSession#rejectMessage?
I wonder also if this logic sit better in AMQSession#notifyConsumer().
It already rejects messages if the consumer is closed. Could it not also
reject messages if the connection is no longer started?
rajith attapattu wrote:
Keith if you look
On Thu, Nov 17, 2011 at 12:03 PM, Gordon Sim g...@redhat.com wrote:
On 11/17/2011 04:57 PM, Ken Giusti wrote:
Hi Justin,
Would it be possible to include the fix for QPID-3626 in the upcoming rc?
https://issues.apache.org/jira/browse/QPID-3626
Without it, any python client that would like
of AMQSession#rejectMessage?
I wonder also if this logic sit better in AMQSession#notifyConsumer().
It already rejects messages if the consumer is closed. Could it not also
reject messages if the connection is no longer started?
rajith attapattu wrote:
Keith if you look
required for? You are releasing a message you
have just received, right? When is that required?
rajith attapattu wrote:
See the above for an explanation for why this is needed.
Gordon Sim wrote:
You mean this is here because of the lack of synchronization with the
dispatcher thread
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2853/#review3325
---
On 2011-11-16 18:31:12, rajith attapattu wrote:
---
This is an automatically generated
it over I think it seems fine due to the
processCompletions call in postDeliver(), but its possibly still worth a
check.
rajith attapattu wrote:
Your observation is correct, this deals with messages that were already
received by the application.
For recover(), we really don't need
-16 18:31:12, rajith attapattu wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2853/
---
(Updated 2011-11-16 18:31:12
You could use -Dqpid.heartbeat=x or use heartbeat as a broker url property.
Btw, Please don't use the AMQ** classes. These are internal classes
that will not be there going forward.
It's better to use the JMS interfaces.
Rajith
On Fri, Nov 18, 2011 at 11:17 AM, Gaston Quezada
As Robbie mentioned, most of the git fans are already using git-svn
(I'm one of them).
So we could perhaps wait for a bit to see how the trial unfolds.
My concern is, that not everybody may be ready to use git at this
point, so if we switch, then we will be disrupting the work for some
folks.
+1 to include this.
This error msg was really annoying :)
Rajith
On Wed, Nov 30, 2011 at 5:14 PM, Robbie Gemmell
robbie.gemm...@gmail.com wrote:
I would like to request merging the fix for QPID-3582: Client
reporting Unable to load custom SASL providers during connection.
The client logs out
On Tue, Dec 6, 2011 at 11:02 AM, Alan Conway acon...@redhat.com wrote:
On 12/06/2011 10:59 AM, Carl Trieloff wrote:
On 12/06/2011 10:56 AM, acon...@apache.org wrote:
NOTE 1: If you are using an ACL, the cluster-username must be allowed to
publish to the qpid.cluster-credentials exchange.
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3041/
---
Review request for qpid, Alan Conway, Gordon Sim, and Kim van der Riet.
Summary
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3041/#review3701
---
On 2011-12-07 01:52:53, rajith attapattu wrote
Yes Gordon alerted me to it last evening.
Weston and I are looking into it.
Rajith
On Fri, Dec 9, 2011 at 3:26 AM, Keith Wall (Reopened) (JIRA)
j...@apache.org wrote:
[
https://issues.apache.org/jira/browse/QPID-3625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
I've added JCA as a component in JIRA.
Regards,
Rajith
On Tue, Dec 20, 2011 at 8:08 AM, Weston M. Price wpr...@redhat.com wrote:
With the completion of
https://issues.apache.org/jira/browse/QPID-3044
there is a new JCA component (actually a sub-component of Java). I was
wondering if it
Assuming your Queue name is my-queue and is already bound to
TopicExchange with an appropriate binding, you can do the following.
destination.my-queue = my-queue
destination.topicExchange = TopicExchange/usa.news
You create your consumer with my-queue and your producer with topicExchange.
Your
On Wed, Dec 21, 2011 at 5:59 AM, eugene eugen.ra...@gmail.com wrote:
Hello Rajith,
Thank you for your answers indeed it helped a lot.
I still have a few questions if I may :-)
1. Why isn't this documented? I mean may be it is but I googled a lot
yesterday and did not find much :(
Have you
On Thu, Dec 22, 2011 at 4:10 AM, eugene eugen.ra...@gmail.com wrote:
Aha - thx for the link. So a subject is really a routing key, right? That is
why I missed it, cause I was looking for a routing key and not subject.
Eugene, sorry for the late reply.
The subject is mapped to the routing key
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2832/
---
(Updated 2012-01-09 19:27:40.039273)
Review request for qpid, Gordon Sim,
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2832/
---
(Updated 2012-01-10 03:52:44.305560)
Review request for qpid, Gordon Sim,
Robbie, you beat me to it :)
Rajith
On Tue, Jan 10, 2012 at 9:09 AM, Robbie Gemmell
robbie.gemm...@gmail.com wrote:
I was literally going to send the same email when i started reading
the thread. The way to set thigns like TTL, priority, deliveryMode is
on the MessageProducer either via the
/java/client/src/main/java/org/apache/qpid/client:
AMQSession.java AMQSession_0_10.java
From: Rajith Attapattu rajit...@gmail.com
To: comm...@qpid.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Virus-Checked: Checked by ClamAV on apache.org
Valid point !
Let me add a note there.
Rajith
On Wed, Jan 25, 2012 at 12:36 PM, Robbie Gemmell
robbie.gemm...@gmail.com wrote:
Can we please ensure to add reasons for tests being excluded from
particular profiles. While its obvious now, after a while it often
becomes less clear which tests
IIRC the no-local argument is passed on during queue-declare.
But if you create a subscription with no-local=true on an existing
queue how should we handle this situation ?
Perhaps there is also a way to pass no-local in the arguments map when
creating a subscription ?
Regards,
Rajith
February 2012 17:36, Rajith Attapattu rajit...@gmail.com wrote:
IIRC the no-local argument is passed on during queue-declare.
But if you create a subscription with no-local=true on an existing
queue how should we handle this situation ?
Perhaps there is also a way to pass no-local in the arguments
On Sun, Feb 19, 2012 at 6:59 PM, Robbie Gemmell
robbie.gemm...@gmail.com wrote:
Hi everyone,
As you may or may not have noticed from the hundreds of emails I have
no doubt generated (I kept some of the traffic off the dev list with
bulk changes, but you cant fix some things in bulk without
As per the discussion on QPID-792, I'm moving the discussion onto the
dev list under.
I have attempted to summarise the current behaviour and some of the
comments expressed by Rob and Robbie.
Currently the clients (C++, python and JMS) resolves an address (with
the 0-10 protocol) as follows.
1.
first email) and then
convert it a Queue or Topic if the Destination object is passed to any
methods that require a Queue/Topic interface.
Regards,
Rajith
On Mon, Feb 27, 2012 at 11:30 PM, Rajith Attapattu rajit...@gmail.com wrote:
As per the discussion on QPID-792, I'm moving the discussion onto
On Tue, Feb 28, 2012 at 3:19 AM, Rob Godfrey rob.j.godf...@gmail.com wrote:
On 28 February 2012 05:37, Rajith Attapattu rajit...@gmail.com wrote:
If the queue and topic qualifiers are used then I guess it makes
it really easy for us to work out the validation.
What are we going to do
, Rajith Attapattu rajit...@gmail.com wrote:
If the queue and topic qualifiers are used then I guess it makes
it really easy for us to work out the validation.
What are we going to do with the destination qualifier ?
Ex destination.my-dest=address-string
1. We deprecate this and get qpid users
missed.
Regards,
Rajith
On Tue, Feb 28, 2012 at 9:53 AM, Rajith Attapattu rajit...@gmail.com wrote:
Rob,
Addressing is indeed a pain point and most of it is due to grey areas
causing undesirable side effects.
I've got some work that I'm hoping to post today.
Let me first check
for sharing your thoughts on this.
Regards,
Rajith
On Wed, Feb 29, 2012 at 7:46 AM, Robbie Gemmell
robbie.gemm...@gmail.com wrote:
On 28 February 2012 17:35, Rajith Attapattu rajit...@gmail.com wrote:
Based on the discussion I would like to outline the following proposal.
I believe it reflects
handled
at configuration time by an administrator than us trying to do the
magic in the code.
Regards,
Rajith
Robbie
On 29 February 2012 15:46, Rajith Attapattu rajit...@gmail.com wrote:
Robbie,
My preference is also to just use queue and topic qualifiers and
deprecate destination , hence listed
how that works already.
Robbie
On 29 February 2012 19:22, Rajith Attapattu rajit...@gmail.com wrote:
On Wed, Feb 29, 2012 at 12:49 PM, Robbie Gemmell
robbie.gemm...@gmail.com wrote:
Just to be clear, I have never been suggesting we remove
'destination.' entries from the equation. I think we
+1 on the dir structure.
I'm not too excited about the name 'amp', but it's not a big deal either :)
It seems this is going to be treated more like a sub project of Qpid
with it's own release schedule, which I believe is the right approach.
Perhaps we should also add a /doc dir to contain the
1 - 100 of 1348 matches
Mail list logo
