Re: Google Summer of Code '09
Aidan Skinner wrote: Hi, I've updated our GSoC ideas page with a brain dump list. http://cwiki.apache.org/confluence/display/qpid/GSoC It's neither complete nor comprehensive. Please add more and flesh out what's there. We should see what ones get filled out into proper ideas that we can promote to the main Apache wiki ASAP. - Aidan This is quite a list. I think we should pull the list of ideas together for this year and then debate the list down to maybe 3 items that we offer up for GSoC. thoughts? Carl. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: message accept confirmation
On Thu, Mar 19, 2009 at 6:31 PM, Dmitriy Kargapolov < dmitriy.kargapo...@gmail.com> wrote: > On Thu, Mar 19, 2009 at 5:42 PM, Dmitriy Kargapolov < > dmitriy.kargapo...@gmail.com> wrote: > >> On Thu, Mar 19, 2009 at 4:00 PM, Gordon Sim wrote: >> >>> Dmitriy Kargapolov wrote: >>> Hi, I'm playing with C++ Qpid broker M4 and .NET client (Win32). Test scenario looks this way: 1) open connection 2) create a session (timeout = 0 sec) 3) declare a queue (durable, exclusive) 4) subscribe to the queue 5) transfer test message to the exchange 6) wait until message arrives from the queue 7) accept the message 8) close session 9) close connection When I run this test, it works just fine. But the message left in the queue after test completed! Second pass returns 2 messages - new and old one, 3rd pass - 3 messages etc. I was able to "fix" this in various ways: 1) If I add short delay (100ms) between steps 7) and 8), accepted message successfully deleted from the queue. Obviously this way is ugly. >>> >>> I'm not very familiar with the .Net client but what I suspect you want to >>> do is sync with the server on or after step 7 to ensure that the server has >>> processed your accept before you exit. >>> >>> I believe session.sync() should do that, or alternatively setting >>> session.setAutoSync(true). As mentioned though, I'm no expert on the .Net >>> client but hopefully Arnaud or others will correct me if thats wrong. >>> >> >> Added sync(): >> session.sync(); >> session.close(); >> client.close(); >> >> This didn't hepl actually. >> Still, if no delay provided before closing session, no 'Accepted' message >> received by broker (checked traces)... >> Looks like some race condition between client threads... >> > > No explicit sync() is required. > What actually solved the problem - setting TCP_NODELAY option in > environment: > > set qpid.tcpNoDelay=true > > This could impact network exchange performance though, in that case the > only solution I see for the moment - pause before closing connection... May > be Devs have an opinion? > > Further investigation shown that the reason was not "incorrect" tcp option. Being not familiar with .NET I placed session.close() and client.close() calls into Destructor of the Object responsible for the communication with Broker. And this object's Destructor was called when Program.Main() ended. I was just shocked realizing that session.close() call never returns. Once it invoked Monitor.Wait(), situation gets out of control - program just silently terminated! Moving cleanup code out of the destructor and its explicit invocation fixed the problem.
[jira] Created: (QPID-1762) java client blows up when it gets a mime type it doesn't recognize
java client blows up when it gets a mime type it doesn't recognize -- Key: QPID-1762 URL: https://issues.apache.org/jira/browse/QPID-1762 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.5 Reporter: Rafael H. Schloming Assignee: Rafael H. Schloming Fix For: 0.5 The java client throws an exception when it gets a mime type it doesn't recognize. This makes interop with non java clients difficult since they sometimes set the mime type to a value for which there is no registered decoder. The java client should really default to decoding as a bytes message in this case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-1761) BBEncoder.grow doesn't properly copy and ends up garbling the encoded data
BBEncoder.grow doesn't properly copy and ends up garbling the encoded data -- Key: QPID-1761 URL: https://issues.apache.org/jira/browse/QPID-1761 Project: Qpid Issue Type: Bug Components: Java Common Affects Versions: 0.5 Reporter: Rafael H. Schloming Assignee: Rafael H. Schloming Fix For: 0.5 BBEncoder.grow doesn't flip the old buffer before copying it to the new buffer. The default buffer size is 4K, so this will only effect messages with more than 4K worth of headers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1731) Need to add a MS Visual Studio project to build qmf-agent
[ https://issues.apache.org/jira/browse/QPID-1731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Huston updated QPID-1731: --- Fix Version/s: 0.6 Issue Type: Improvement (was: Bug) Affects Version/s: 0.5 > Need to add a MS Visual Studio project to build qmf-agent > - > > Key: QPID-1731 > URL: https://issues.apache.org/jira/browse/QPID-1731 > Project: Qpid > Issue Type: Improvement > Components: C++ Client >Affects Versions: 0.5 > Environment: Windows, VC9 >Reporter: Steve Huston >Assignee: Steve Huston >Priority: Minor > Fix For: 0.6 > > > Pete MacKinnon reported in QPID-1673: > "There appears to be no MS project for the qmf-agent example in the branch. > Was this intentional or an oversight?" > It hasn't yet been added for Windows. It should be. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-1731) Need to add a MS Visual Studio project to build qmf-agent
[ https://issues.apache.org/jira/browse/QPID-1731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683669#action_12683669 ] Steve Huston commented on QPID-1731: Hi Pete, You need not have it assigned to attach... maybe you couldn't because it was closed? I reopened it - let me know if there's a problem with attaching your patches. Thanks. -Steve > Need to add a MS Visual Studio project to build qmf-agent > - > > Key: QPID-1731 > URL: https://issues.apache.org/jira/browse/QPID-1731 > Project: Qpid > Issue Type: Improvement > Components: C++ Client >Affects Versions: 0.5 > Environment: Windows, VC9 >Reporter: Steve Huston >Assignee: Steve Huston >Priority: Minor > Fix For: 0.6 > > > Pete MacKinnon reported in QPID-1673: > "There appears to be no MS project for the qmf-agent example in the branch. > Was this intentional or an oversight?" > It hasn't yet been added for Windows. It should be. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Reopened: (QPID-1731) Need to add a MS Visual Studio project to build qmf-agent
[ https://issues.apache.org/jira/browse/QPID-1731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Huston reopened QPID-1731: > Need to add a MS Visual Studio project to build qmf-agent > - > > Key: QPID-1731 > URL: https://issues.apache.org/jira/browse/QPID-1731 > Project: Qpid > Issue Type: Bug > Components: C++ Client > Environment: Windows, VC9 >Reporter: Steve Huston >Assignee: Steve Huston >Priority: Minor > > Pete MacKinnon reported in QPID-1673: > "There appears to be no MS project for the qmf-agent example in the branch. > Was this intentional or an oversight?" > It hasn't yet been added for Windows. It should be. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: message accept confirmation
On Thu, Mar 19, 2009 at 5:42 PM, Dmitriy Kargapolov < dmitriy.kargapo...@gmail.com> wrote: > On Thu, Mar 19, 2009 at 4:00 PM, Gordon Sim wrote: > >> Dmitriy Kargapolov wrote: >> >>> Hi, >>> I'm playing with C++ Qpid broker M4 and .NET client (Win32). >>> Test scenario looks this way: >>> 1) open connection >>> 2) create a session (timeout = 0 sec) >>> 3) declare a queue (durable, exclusive) >>> 4) subscribe to the queue >>> 5) transfer test message to the exchange >>> 6) wait until message arrives from the queue >>> 7) accept the message >>> 8) close session >>> 9) close connection >>> >>> When I run this test, it works just fine. But the message left in the >>> queue >>> after test completed! Second pass returns 2 messages - new and old one, >>> 3rd >>> pass - 3 messages etc. >>> >>> I was able to "fix" this in various ways: >>> 1) If I add short delay (100ms) between steps 7) and 8), accepted message >>> successfully deleted from the queue. >>> Obviously this way is ugly. >>> >> >> I'm not very familiar with the .Net client but what I suspect you want to >> do is sync with the server on or after step 7 to ensure that the server has >> processed your accept before you exit. >> >> I believe session.sync() should do that, or alternatively setting >> session.setAutoSync(true). As mentioned though, I'm no expert on the .Net >> client but hopefully Arnaud or others will correct me if thats wrong. >> > > Added sync(): > session.sync(); > session.close(); > client.close(); > > This didn't hepl actually. > Still, if no delay provided before closing session, no 'Accepted' message > received by broker (checked traces)... > Looks like some race condition between client threads... > No explicit sync() is required. What actually solved the problem - setting TCP_NODELAY option in environment: set qpid.tcpNoDelay=true This could impact network exchange performance though, in that case the only solution I see for the moment - pause before closing connection... May be Devs have an opinion?
[jira] Updated: (QPID-1760) Improve toString method for JMSMessage
[ https://issues.apache.org/jira/browse/QPID-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajith Attapattu updated QPID-1760: --- Status: Ready To Review (was: In Progress) > Improve toString method for JMSMessage > -- > > Key: QPID-1760 > URL: https://issues.apache.org/jira/browse/QPID-1760 > Project: Qpid > Issue Type: Improvement > Components: Java Client >Reporter: Rajith Attapattu >Assignee: Rajith Attapattu > Fix For: 0.6 > > > Currently the toString method does not print any meaningful information for > Byte, Stream or Map message. > The AbstractJMSMethod is also not printing the replyTo (if available) and > also printing the properties in one line which makes it a bit unreadable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-1760) Improve toString method for JMSMessage
[ https://issues.apache.org/jira/browse/QPID-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683637#action_12683637 ] Rajith Attapattu commented on QPID-1760: I have commited a fix in Qpid trunk at rev 756228. The AbstractBytesMessage will now use the toString method from AbstractJMSMessage Also I have modified the toBodyString method in AbstractBytesMessage to use a function that can handle unprintable charachters and print contents upto a maximum of 100 bytes. > Improve toString method for JMSMessage > -- > > Key: QPID-1760 > URL: https://issues.apache.org/jira/browse/QPID-1760 > Project: Qpid > Issue Type: Improvement > Components: Java Client >Reporter: Rajith Attapattu >Assignee: Rajith Attapattu > Fix For: 0.6 > > > Currently the toString method does not print any meaningful information for > Byte, Stream or Map message. > The AbstractJMSMethod is also not printing the replyTo (if available) and > also printing the properties in one line which makes it a bit unreadable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-1760) Improve toString method for JMSMessage
Improve toString method for JMSMessage -- Key: QPID-1760 URL: https://issues.apache.org/jira/browse/QPID-1760 Project: Qpid Issue Type: Improvement Components: Java Client Reporter: Rajith Attapattu Assignee: Rajith Attapattu Fix For: 0.6 Currently the toString method does not print any meaningful information for Byte, Stream or Map message. The AbstractJMSMethod is also not printing the replyTo (if available) and also printing the properties in one line which makes it a bit unreadable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: AMQP 1.0
Aidan Skinner wrote: The Java client uses JMS for this to an extent, but we still need a way of exposing AMQP specific things in ways that are as version independent as possible (such as the mandatory flag). I can see that there is value in reaching out to developers who have JMS code or who wish to retain JMS capability, *please* don't hobble Java users who want the full-fat qpid experience by making everything fit with JMS. Case in point: the Java client for postgres is annoyingly limited as soon as you want to receive async notifications and so on. I would much prefer the most efficient and direct mapping to AMQP facilities possible in each language, and an adapter to legacy APIs. Sun's failure to consider interoperability with other language environments continues to haunt it. :-( There is much to learn from ActiveMQ interoperability. There are lots of JMS implementations. My own interest in AMQP is largely driven by it NOT being JMS - so there is a chance that my C#, Python and C++ code can be first class citizens. Clearly other people will have different priorities. I'm interested to know why a (happy) JMS user would be interested in AMQP though: JMS has things which are handy in Java but will be awkward in a heterogeneous system. Perhaps something to consider is trying to make the C/C++ client as lightweight as possible and having a reference SWIG wrapper. In this case I would ideally look for the client to be 'passive' and allow the host to do raw connection establishment and raw IO so it acts as a protocol engine and avoid issues of event loop integration and so on. James - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: AMQP 1.0
James Mansion wrote: Gordon Sim wrote: Another important aspect is ensuring that adding support for 1.0 doesn't break previously supported versions. How important is that, really? There is no version overlap in the Java and C++ brokers currently. You aren't at v1.0 yet, of AMQP or QPid. For me it is essential. Is anyone actually in production? Yes. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: AMQP 1.0
Gordon Sim wrote: For me the first part of the process is a protocol independent API and some thinking around how to support multiple protocols in the broker (allowing messages published over one protocol to be delivered over another etc). You mean an internal support API into which the 1.0 and 0.10 bits etc can be plugged? Another important aspect is ensuring that adding support for 1.0 doesn't break previously supported versions. How important is that, really? There is no version overlap in the Java and C++ brokers currently. You aren't at v1.0 yet, of AMQP or QPid. Is anyone actually in production? Thank you very much for investing your time in the project, it is great to have your interest! You could read to much into it. I'm trying to warn that my interest isn't realistically going to result in coding. I can think about things, comment, and play. But I can't contribute in a 'show me the code' way. Some projects can't accomodate that. I can see why there is a preference for action rather than bike-shed design, but it does limit the sort of contribution that people can make - after all, even a prioritisation of features from potential users is a contribution at some level. James - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-1731) Need to add a MS Visual Studio project to build qmf-agent
[ https://issues.apache.org/jira/browse/QPID-1731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683585#action_12683585 ] Pete MacKinnon commented on QPID-1731: -- Steve, can you assign this to me? I have some patches I'd like to submit for the lib and example. \Pete > Need to add a MS Visual Studio project to build qmf-agent > - > > Key: QPID-1731 > URL: https://issues.apache.org/jira/browse/QPID-1731 > Project: Qpid > Issue Type: Bug > Components: C++ Client > Environment: Windows, VC9 >Reporter: Steve Huston >Assignee: Steve Huston >Priority: Minor > > Pete MacKinnon reported in QPID-1673: > "There appears to be no MS project for the qmf-agent example in the branch. > Was this intentional or an oversight?" > It hasn't yet been added for Windows. It should be. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: AMQP 1.0
Sorry to send twice. Our mail server is being flaky and appeared to drop
the first one.
--Rafael
Rafael Schloming wrote:
Robert Godfrey wrote:
[.. snip ..]
I tend to dislike the casting approach since if you need to make more
than
one or two calls it becomes quite cumbersome and people then
inevitably just
declare their variables to be of the non JMS type and then it's unclear
which calls are pure JMS and which aren't.
I also think it's a bit of a hack to be required to cast as part of
an API.
It's difficult to tell whether you're casting into an approved part
of the
API or whether you're casting to some random implementation specific
interface that the object just happens to implement.
That is why I advocate an *interface* rather than casting into
implementation classes.
An interface if restricted to only permit features not accessible
through vanilla JMS would certainly help, but I still think casting as
part of the API unacceptably blurs the boundaries of the API. There is
no way to tell what types you're allowed to cast and which interfaces
you're allowed to cast it to.
Using custom headers hides dependencies and makes things compile (or
link) even when they should fail.
This is only true if you hardcode your header values rather than
using some
API to set them. Using constants will cause a compile time failure, and
using a decorator will cause both compile and link failures.
It will cause a compile time failure but not a run time failure. You
can have the jar in your classpath without it being the JMS client
that you are actually using.
Yes, I was considering that a feature. It doesn't matter whether you
have an 0-8, 0-9, 0-10, or 1-0 JMS message underneath, you still have
access to the same broker extension. I would probably add an assertion
based on the destination, broker vendor/version, etc to verify that the
broker and recipient will understand what is being sent.
I think there are different sorts of AMQP specific behavior that we
need to
think about here. For example I would make a distinction between AMQP or
Qpid specific broker features, and AMQP or Qpid specific client
features. I
think accessing AMQP or Qpid specific broker features through a well
defined
set of message headers is probably a reasonable way to go, and there
are a
variety of ways to set these headers that provide differing levels of
compile and/or runtime protection to the application. But really for
accessing broker features there is no need to tie anything to the
specific
JMS implementation in question, e.g.:
Message msg = ..;
QpidMessage qmsg = new QpidMessage(msg);
qmsg.setFoo(); // equivalent to msg.setStringProperty(QpidHeaders.FOO,
"bar") which is in turn equivalent to
msg.setStringProperty("org.apache.qpid.foo", "bar")
I think the JMS Properties should be used as intended - that is as a
way of adding to the end-to-end properties of the message (payload)
being sent. If the extension is on the broker, and is triggered by
such a property then setting the property is the appropriate
mechanism. However if the AMQP extension is something that should be
interpreted by the client then I do not believe that we should be
using such an ugly hack.
I wasn't suggesting using headers for controlling client local behavior.
I think actually we should take appropriate advantage of the destination
abstraction for that.
I understand that you have a pathalogical hatred of casts. The java
syntax is certainly less than ideal. However where we are depending
on AMQP specific behaviour it should be called out.
It's not casts I dislike. It's casting as part of an API that I dislike
since it makes the API unnecessarily blurry. It's also quite trivial to
avoid assuming you don't have a pathological hatred of static methods. ;)
My feeling is that given where we are taking the 1-0 spec there is
likely to be *much* less of this required.
The only examples I can think of off-hand on messages might be audit
trails or signatures...
Yes, I think most extensions are actually likely to be more Qpid
specific than AMQP specific as well.
For AMQP or Qpid specific behavior related to the client implementation,
e.g. acking behavior, prefetch behavior, etc, I think this is
something of a
different story, and I would probably take these features on a case
by case
basis. I suspect it's probably not an either/or situation and we'll want
both configuration for people deploying pre-existing vanilla JMS
apps, as
well as API for people writing stuff from scratch or "porting" to qpid.
My view is that you should try to avoid to using *any* AMQP or Qpid
specific extensions. Where they are to be relied upon I (as an
architect or manager of a development team) want those dependencies to
be called out *very* explicitly. The use of magic headers etc. is the
sort of thing that makes porting between message providers *very* hard
(been there done that).
I wasn't suggesting using magic headers for this sort of th
Re: AMQP 1.0
Robert Godfrey wrote:
[.. snip ..]
I tend to dislike the casting approach since if you need to make more than
one or two calls it becomes quite cumbersome and people then inevitably just
declare their variables to be of the non JMS type and then it's unclear
which calls are pure JMS and which aren't.
I also think it's a bit of a hack to be required to cast as part of an API.
It's difficult to tell whether you're casting into an approved part of the
API or whether you're casting to some random implementation specific
interface that the object just happens to implement.
That is why I advocate an *interface* rather than casting into
implementation classes.
An interface if restricted to only permit features not accessible
through vanilla JMS would certainly help, but I still think casting as
part of the API unacceptably blurs the boundaries of the API. There is
no way to tell what types you're allowed to cast and which interfaces
you're allowed to cast it to.
Using custom headers hides dependencies and makes things compile (or
link) even when they should fail.
This is only true if you hardcode your header values rather than using some
API to set them. Using constants will cause a compile time failure, and
using a decorator will cause both compile and link failures.
It will cause a compile time failure but not a run time failure. You
can have the jar in your classpath without it being the JMS client
that you are actually using.
Yes, I was considering that a feature. It doesn't matter whether you
have an 0-8, 0-9, 0-10, or 1-0 JMS message underneath, you still have
access to the same broker extension. I would probably add an assertion
based on the destination, broker vendor/version, etc to verify that the
broker and recipient will understand what is being sent.
I think there are different sorts of AMQP specific behavior that we need to
think about here. For example I would make a distinction between AMQP or
Qpid specific broker features, and AMQP or Qpid specific client features. I
think accessing AMQP or Qpid specific broker features through a well defined
set of message headers is probably a reasonable way to go, and there are a
variety of ways to set these headers that provide differing levels of
compile and/or runtime protection to the application. But really for
accessing broker features there is no need to tie anything to the specific
JMS implementation in question, e.g.:
Message msg = ..;
QpidMessage qmsg = new QpidMessage(msg);
qmsg.setFoo(); // equivalent to msg.setStringProperty(QpidHeaders.FOO,
"bar") which is in turn equivalent to
msg.setStringProperty("org.apache.qpid.foo", "bar")
I think the JMS Properties should be used as intended - that is as a
way of adding to the end-to-end properties of the message (payload)
being sent. If the extension is on the broker, and is triggered by
such a property then setting the property is the appropriate
mechanism. However if the AMQP extension is something that should be
interpreted by the client then I do not believe that we should be
using such an ugly hack.
I wasn't suggesting using headers for controlling client local behavior.
I think actually we should take appropriate advantage of the destination
abstraction for that.
I understand that you have a pathalogical hatred of casts. The java
syntax is certainly less than ideal. However where we are depending
on AMQP specific behaviour it should be called out.
It's not casts I dislike. It's casting as part of an API that I dislike
since it makes the API unnecessarily blurry. It's also quite trivial to
avoid assuming you don't have a pathological hatred of static methods. ;)
My feeling is that given where we are taking the 1-0 spec there is
likely to be *much* less of this required.
The only examples I can think of off-hand on messages might be audit
trails or signatures...
Yes, I think most extensions are actually likely to be more Qpid
specific than AMQP specific as well.
For AMQP or Qpid specific behavior related to the client implementation,
e.g. acking behavior, prefetch behavior, etc, I think this is something of a
different story, and I would probably take these features on a case by case
basis. I suspect it's probably not an either/or situation and we'll want
both configuration for people deploying pre-existing vanilla JMS apps, as
well as API for people writing stuff from scratch or "porting" to qpid.
My view is that you should try to avoid to using *any* AMQP or Qpid
specific extensions. Where they are to be relied upon I (as an
architect or manager of a development team) want those dependencies to
be called out *very* explicitly. The use of magic headers etc. is the
sort of thing that makes porting between message providers *very* hard
(been there done that).
I wasn't suggesting using magic headers for this sort of thing. I think
the destination abstraction can be used for most of what we need here.
Hopefully most AMQP/QPID extensions can be isolated in
Re: AMQP 1.0
Robert Godfrey wrote:
[.. snip ..]
I tend to dislike the casting approach since if you need to make more than
one or two calls it becomes quite cumbersome and people then inevitably just
declare their variables to be of the non JMS type and then it's unclear
which calls are pure JMS and which aren't.
I also think it's a bit of a hack to be required to cast as part of an API.
It's difficult to tell whether you're casting into an approved part of the
API or whether you're casting to some random implementation specific
interface that the object just happens to implement.
That is why I advocate an *interface* rather than casting into
implementation classes.
An interface if restricted to only permit features not accessible
through vanilla JMS would certainly help, but I still think casting as
part of the API unacceptably blurs the boundaries of the API. There is
no way to tell what types you're allowed to cast and to which interfaces
you're allowed to cast.
Using custom headers hides dependencies and makes things compile (or
link) even when they should fail.
This is only true if you hardcode your header values rather than using some
API to set them. Using constants will cause a compile time failure, and
using a decorator will cause both compile and link failures.
It will cause a compile time failure but not a run time failure. You
can have the jar in your classpath without it being the JMS client
that you are actually using.
Yes, I was considering that a feature. It doesn't matter whether you
have an 0-8, 0-9, 0-10, or 1-0 JMS message underneath, you still have
access to the same broker extension. I would probably add an assertion
based on the destination, broker vendor/version, etc to verify that the
broker and recipient will understand what is being sent.
I think there are different sorts of AMQP specific behavior that we need to
think about here. For example I would make a distinction between AMQP or
Qpid specific broker features, and AMQP or Qpid specific client features. I
think accessing AMQP or Qpid specific broker features through a well defined
set of message headers is probably a reasonable way to go, and there are a
variety of ways to set these headers that provide differing levels of
compile and/or runtime protection to the application. But really for
accessing broker features there is no need to tie anything to the specific
JMS implementation in question, e.g.:
Message msg = ..;
QpidMessage qmsg = new QpidMessage(msg);
qmsg.setFoo(); // equivalent to msg.setStringProperty(QpidHeaders.FOO,
"bar") which is in turn equivalent to
msg.setStringProperty("org.apache.qpid.foo", "bar")
I think the JMS Properties should be used as intended - that is as a
way of adding to the end-to-end properties of the message (payload)
being sent. If the extension is on the broker, and is triggered by
such a property then setting the property is the appropriate
mechanism. However if the AMQP extension is something that should be
interpreted by the client then I do not believe that we should be
using such an ugly hack.
I wasn't suggesting using headers for controlling client local behavior.
I think actually we should take appropriate advantage of the destination
abstraction for that.
I understand that you have a pathalogical hatred of casts. The java
syntax is certainly less than ideal. However where we are depending
on AMQP specific behaviour it should be called out.
It's not casts I dislike. It's casting as part of an API that I dislike
since it makes the API unnecessarily blurry. It's also quite trivial to
avoid assuming you don't have a pathological hatred of static methods. ;)
My feeling is that given where we are taking the 1-0 spec there is
likely to be *much* less of this required.
The only examples I can think of off-hand on messages might be audit
trails or signatures...
Yes, I think most extensions are actually likely to be more Qpid
specific than AMQP specific as well.
For AMQP or Qpid specific behavior related to the client implementation,
e.g. acking behavior, prefetch behavior, etc, I think this is something of a
different story, and I would probably take these features on a case by case
basis. I suspect it's probably not an either/or situation and we'll want
both configuration for people deploying pre-existing vanilla JMS apps, as
well as API for people writing stuff from scratch or "porting" to qpid.
My view is that you should try to avoid to using *any* AMQP or Qpid
specific extensions. Where they are to be relied upon I (as an
architect or manager of a development team) want those dependencies to
be called out *very* explicitly. The use of magic headers etc. is the
sort of thing that makes porting between message providers *very* hard
(been there done that).
I wasn't suggesting using magic headers for this sort of thing. I think
we can do most of what we need to through the destination abstraction.
Hopefully most AMQP/QPID extensions can
message accept confirmation
Hi, I'm playing with C++ Qpid broker M4 and .NET client (Win32). Test scenario looks this way: 1) open connection 2) create a session (timeout = 0 sec) 3) declare a queue (durable, exclusive) 4) subscribe to the queue 5) transfer test message to the exchange 6) wait until message arrives from the queue 7) accept the message 8) close session 9) close connection When I run this test, it works just fine. But the message left in the queue after test completed! Second pass returns 2 messages - new and old one, 3rd pass - 3 messages etc. I was able to "fix" this in various ways: 1) If I add short delay (100ms) between steps 7) and 8), accepted message successfully deleted from the queue. Obviously this way is ugly. 2) If session is created with some expiration timeout, 1st try works fine. But second try got locked due to exclusive subscription of the 1st session which still exists in the broker (until timeout expired). Definitely this is not what I want. What I do not understand - why message didn't get deleted when session closed? I'm sure, accept command reached broker _before_ session ends. Is it bug or normal behavior per AMQP 0-10 spec? Is there any elegant way to make sure accepted message was actually deleted from the queue before leaving session? Thank you.
Re: Google Summer of Code '09
Hi Aidan, I'm gonna give a shot to Apache GSOC people about my last experience I had in GSOC 2008 during ApacheCon. I did it at ApacheCon US too and probably they'll be able to allocate more than two projects for Qpid this time. Lahiru On Thu, Mar 19, 2009 at 9:36 AM, Aidan Skinner wrote: > Hi, > > I've updated our GSoC ideas page with a brain dump list. > http://cwiki.apache.org/confluence/display/qpid/GSoC > > It's neither complete nor comprehensive. Please add more and flesh out > what's there. We should see what ones get filled out into proper ideas > that we can promote to the main Apache wiki ASAP. > > - Aidan > -- > Apache Qpid - World Domination through Advanced Message Queueing > http://qpid.apache.org > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > > -- Apache Qpid, Worlds dominant messaging middleware..!!!
Re: AMQP 1.0
[.. snip ..]
> I tend to dislike the casting approach since if you need to make more than
> one or two calls it becomes quite cumbersome and people then inevitably just
> declare their variables to be of the non JMS type and then it's unclear
> which calls are pure JMS and which aren't.
>
> I also think it's a bit of a hack to be required to cast as part of an API.
> It's difficult to tell whether you're casting into an approved part of the
> API or whether you're casting to some random implementation specific
> interface that the object just happens to implement.
That is why I advocate an *interface* rather than casting into
implementation classes.
>> Using custom headers hides dependencies and makes things compile (or
>> link) even when they should fail.
>
> This is only true if you hardcode your header values rather than using some
> API to set them. Using constants will cause a compile time failure, and
> using a decorator will cause both compile and link failures.
It will cause a compile time failure but not a run time failure. You
can have the jar in your classpath without it being the JMS client
that you are actually using.
> I think there are different sorts of AMQP specific behavior that we need to
> think about here. For example I would make a distinction between AMQP or
> Qpid specific broker features, and AMQP or Qpid specific client features. I
> think accessing AMQP or Qpid specific broker features through a well defined
> set of message headers is probably a reasonable way to go, and there are a
> variety of ways to set these headers that provide differing levels of
> compile and/or runtime protection to the application. But really for
> accessing broker features there is no need to tie anything to the specific
> JMS implementation in question, e.g.:
>
> Message msg = ..;
> QpidMessage qmsg = new QpidMessage(msg);
> qmsg.setFoo(); // equivalent to msg.setStringProperty(QpidHeaders.FOO,
> "bar") which is in turn equivalent to
> msg.setStringProperty("org.apache.qpid.foo", "bar")
I think the JMS Properties should be used as intended - that is as a
way of adding to the end-to-end properties of the message (payload)
being sent. If the extension is on the broker, and is triggered by
such a property then setting the property is the appropriate
mechanism. However if the AMQP extension is something that should be
interpreted by the client then I do not believe that we should be
using such an ugly hack.
I understand that you have a pathalogical hatred of casts. The java
syntax is certainly less than ideal. However where we are depending
on AMQP specific behaviour it should be called out.
My feeling is that given where we are taking the 1-0 spec there is
likely to be *much* less of this required.
The only examples I can think of off-hand on messages might be audit
trails or signatures...
> For AMQP or Qpid specific behavior related to the client implementation,
> e.g. acking behavior, prefetch behavior, etc, I think this is something of a
> different story, and I would probably take these features on a case by case
> basis. I suspect it's probably not an either/or situation and we'll want
> both configuration for people deploying pre-existing vanilla JMS apps, as
> well as API for people writing stuff from scratch or "porting" to qpid.
>
My view is that you should try to avoid to using *any* AMQP or Qpid
specific extensions. Where they are to be relied upon I (as an
architect or manager of a development team) want those dependencies to
be called out *very* explicitly. The use of magic headers etc. is the
sort of thing that makes porting between message providers *very* hard
(been there done that).
Hopefully most AMQP/QPID extensions can be isolated in cofiguration
rather than code...
--Rob
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: AMQP 1.0
Robert Godfrey wrote:
2009/3/19 Rajith Attapattu :
On Thu, Mar 19, 2009 at 9:40 AM, Aidan Skinner wrote:
On Thu, Mar 19, 2009 at 1:29 PM, Rajith Attapattu wrote:
On Thu, Mar 19, 2009 at 6:36 AM, Aidan Skinner wrote:
On Wed, Mar 18, 2009 at 8:26 PM, Gordon Sim wrote:
The Java client uses JMS for this to an extent, but we still need a
way of exposing AMQP specific things in ways that are as version
independent as possible (such as the mandatory flag). I've been
kicking around the idea of something like this:
I am of the opinion that you could get 99% of the AMQP stuff while
still using pure JMS.
I have a few ideas around how to do the immediate flag etc while still
using pure JMS.
One such idea is to pass in a QPID specific property in the message
called "AMQP_IMMEDIATE" and the respective sender method can look for
the presense of this flag and put that in the delivery props. When
See, I'm not sure this is really "pure JMS". It may not use any
non-JMS API, but it does rely on non-JMS semantics.
I can easily see that this improves portability from a "does my code
compile" PoV. I think it may be quite unhelpful from a "does my code
still work" PoV however. Having non-JMS features available as non-JMS
API at least makes their dependence on this more obvious.
I completely agree with Aidan's point here.
Frankly if you are relying on AMQP specific semantics then you should
make this clear in the code.
Personally I would think
if(msg instanceof AMQMessage)
{
((AMQMessage)msg).setImmediate(true);
}
I tend to dislike the casting approach since if you need to make more
than one or two calls it becomes quite cumbersome and people then
inevitably just declare their variables to be of the non JMS type and
then it's unclear which calls are pure JMS and which aren't.
I also think it's a bit of a hack to be required to cast as part of an
API. It's difficult to tell whether you're casting into an approved part
of the API or whether you're casting to some random implementation
specific interface that the object just happens to implement.
Using custom headers hides dependencies and makes things compile (or
link) even when they should fail.
This is only true if you hardcode your header values rather than using
some API to set them. Using constants will cause a compile time failure,
and using a decorator will cause both compile and link failures.
I think there are different sorts of AMQP specific behavior that we need
to think about here. For example I would make a distinction between AMQP
or Qpid specific broker features, and AMQP or Qpid specific client
features. I think accessing AMQP or Qpid specific broker features
through a well defined set of message headers is probably a reasonable
way to go, and there are a variety of ways to set these headers that
provide differing levels of compile and/or runtime protection to the
application. But really for accessing broker features there is no need
to tie anything to the specific JMS implementation in question, e.g.:
Message msg = ..;
QpidMessage qmsg = new QpidMessage(msg);
qmsg.setFoo(); // equivalent to msg.setStringProperty(QpidHeaders.FOO,
"bar") which is in turn equivalent to
msg.setStringProperty("org.apache.qpid.foo", "bar")
For AMQP or Qpid specific behavior related to the client implementation,
e.g. acking behavior, prefetch behavior, etc, I think this is something
of a different story, and I would probably take these features on a case
by case basis. I suspect it's probably not an either/or situation and
we'll want both configuration for people deploying pre-existing vanilla
JMS apps, as well as API for people writing stuff from scratch or
"porting" to qpid.
--Rafael
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
Google Summer of Code '09
Hi, I've updated our GSoC ideas page with a brain dump list. http://cwiki.apache.org/confluence/display/qpid/GSoC It's neither complete nor comprehensive. Please add more and flesh out what's there. We should see what ones get filled out into proper ideas that we can promote to the main Apache wiki ASAP. - Aidan -- Apache Qpid - World Domination through Advanced Message Queueing http://qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: AMQP 1.0
On Thu, Mar 19, 2009 at 2:05 PM, Rajith Attapattu wrote: > Based on my experience with end users I found that people are very > keen on sticking to the JMS API's as much as possible. > Most of them were moving from an existing JMS provider to Qpid. > If they have to use anything vendor specific their strong preference > was to use configuration files, jvm arguments, flags etc... > Using non JMS API's is something they want to avoid as much as possible. > > So from an end users pov, when switching a provider I would like to do > as less work as possible and having portable code is a big plus point > IMO. > Even for an existing Qpid user, when switching from an 0-8/0-9 to 0-10 > to 1.0 this approach IMO provides a more pain free strategy. I totally understand this desire for portability, and I can see why users would benefit from sticking to JMS APIs wherever possible. My point is that writing portable JMS requires not just passing the right parameters to the right methods, but expecting the correct semantics from those parameters. It doesn't help my app's portability if it turns out that I also need to put a magic string into a properties file for it to work as I expect. That's something that's likely to be found in QA. IMO, it's much better for me to have to cast to something that specifically identifies the depedency and, hopefully, has a comment about why that's there. That's something that the compiler picks up when I swap out on JMS provider for another. - Aidan -- Apache Qpid - World Domination through Advanced Message Queueing http://qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: AMQP 1.0
On Thu, Mar 19, 2009 at 3:06 PM, Robert Godfrey wrote: > is entirely appropriate. Best would be if AMQMessage was defined by > the AMQP Working Group and provided in an org.amqp package... That would be Very Helpful indeed, although quite a big task. ;) We could work on it on org.apache.qpid.amqp and try to sync up with other vendors if other people were interested. > On the interfaces side, what I was saying was that AMQMessage need not > extend JMS Message, etc... Our *implementation* of a Message class > would likely implement both. Ah, ok. Gotcha. This seems sensible. > My main concern would be if there were any legal implications to > publishing a set of AMQP interfaces that depended on the JMS ones... Possibly, though IANAL nor do I play one on tv. It's probably not desireable in any case, hard casts out of JMS are probably semantically clearer. - Aidan -- Apache Qpid - World Domination through Advanced Message Queueing http://qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: AMQP 1.0
2009/3/19 Rajith Attapattu :
> On Thu, Mar 19, 2009 at 9:40 AM, Aidan Skinner wrote:
>> On Thu, Mar 19, 2009 at 1:29 PM, Rajith Attapattu wrote:
>>> On Thu, Mar 19, 2009 at 6:36 AM, Aidan Skinner wrote:
On Wed, Mar 18, 2009 at 8:26 PM, Gordon Sim wrote:
>>
The Java client uses JMS for this to an extent, but we still need a
way of exposing AMQP specific things in ways that are as version
independent as possible (such as the mandatory flag). I've been
kicking around the idea of something like this:
>>>
>>> I am of the opinion that you could get 99% of the AMQP stuff while
>>> still using pure JMS.
>>> I have a few ideas around how to do the immediate flag etc while still
>>> using pure JMS.
>>> One such idea is to pass in a QPID specific property in the message
>>> called "AMQP_IMMEDIATE" and the respective sender method can look for
>>> the presense of this flag and put that in the delivery props. When
>>
>> See, I'm not sure this is really "pure JMS". It may not use any
>> non-JMS API, but it does rely on non-JMS semantics.
>>
>> I can easily see that this improves portability from a "does my code
>> compile" PoV. I think it may be quite unhelpful from a "does my code
>> still work" PoV however. Having non-JMS features available as non-JMS
>> API at least makes their dependence on this more obvious.
I completely agree with Aidan's point here.
Frankly if you are relying on AMQP specific semantics then you should
make this clear in the code.
Personally I would think
if(msg instanceof AMQMessage)
{
((AMQMessage)msg).setImmediate(true);
}
is entirely appropriate. Best would be if AMQMessage was defined by
the AMQP Working Group and provided in an org.amqp package...
[aside - immediate is a really terrible example here as it is not
something that exists in 1-0].
Using custom headers hides dependencies and makes things compile (or
link) even when they should fail.
Implementation wise the current (0-8/0-9) / 0-10 multiversion stuff is
a bit of / complete nightmare.
I think the 1-0 code should be *much more* separate from the existing code.
On the interfaces side, what I was saying was that AMQMessage need not
extend JMS Message, etc... Our *implementation* of a Message class
would likely implement both.
My main concern would be if there were any legal implications to
publishing a set of AMQP interfaces that depended on the JMS ones...
-- Rob
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-1759) Unit tests fail on Fedora 10 when gcc-debuginfo is installed
Unit tests fail on Fedora 10 when gcc-debuginfo is installed Key: QPID-1759 URL: https://issues.apache.org/jira/browse/QPID-1759 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.5 Environment: Fedora 10 i386 Reporter: Ted Ross Priority: Minor When gcc-debuginfo is installed, the unit tests fail because the ephemeral port cannot be determined for the broker. After digging a little further, I determined that streams do not handle numeric data. For example, if I put the following line in the broker code: std::cout << "string " << 45 << " string2" << std::endl; the output seen on the console is: string The number and any following text is lost (probably due to a null-terminator being incorrectly inserted). Note that this does not affect normal broker operation, nor does it affect the python system tests. It only affects the broker running in the unit test environment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-1758) Add AMQP options on queue.delete, queue.declare, exchange.declare in qpid-config
[ https://issues.apache.org/jira/browse/QPID-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved QPID-1758. Resolution: Fixed Fix Version/s: 0.6 > Add AMQP options on queue.delete, queue.declare, exchange.declare in > qpid-config > > > Key: QPID-1758 > URL: https://issues.apache.org/jira/browse/QPID-1758 > Project: Qpid > Issue Type: Improvement > Components: python tools >Affects Versions: M4 >Reporter: Ffrench Mathilde >Assignee: Ted Ross >Priority: Trivial > Fix For: 0.6 > > Attachments: qpid-config.diff > > > Add some useful options to queue.delete, queue.declare, exchange.declare in > qpid-config : > queue.delete : if_unused and if_empty > queue.declare : alternate_exchange, passive, exclusive > exchange.declare : alternate_exchange, passive -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: AMQP 1.0
On Thu, Mar 19, 2009 at 9:40 AM, Aidan Skinner wrote: > On Thu, Mar 19, 2009 at 1:29 PM, Rajith Attapattu wrote: >> On Thu, Mar 19, 2009 at 6:36 AM, Aidan Skinner wrote: >>> On Wed, Mar 18, 2009 at 8:26 PM, Gordon Sim wrote: > >>> The Java client uses JMS for this to an extent, but we still need a >>> way of exposing AMQP specific things in ways that are as version >>> independent as possible (such as the mandatory flag). I've been >>> kicking around the idea of something like this: >>> >> >> I am of the opinion that you could get 99% of the AMQP stuff while >> still using pure JMS. >> I have a few ideas around how to do the immediate flag etc while still >> using pure JMS. >> One such idea is to pass in a QPID specific property in the message >> called "AMQP_IMMEDIATE" and the respective sender method can look for >> the presense of this flag and put that in the delivery props. When > > See, I'm not sure this is really "pure JMS". It may not use any > non-JMS API, but it does rely on non-JMS semantics. > > I can easily see that this improves portability from a "does my code > compile" PoV. I think it may be quite unhelpful from a "does my code > still work" PoV however. Having non-JMS features available as non-JMS > API at least makes their dependence on this more obvious. Based on my experience with end users I found that people are very keen on sticking to the JMS API's as much as possible. Most of them were moving from an existing JMS provider to Qpid. If they have to use anything vendor specific their strong preference was to use configuration files, jvm arguments, flags etc... Using non JMS API's is something they want to avoid as much as possible. So from an end users pov, when switching a provider I would like to do as less work as possible and having portable code is a big plus point IMO. Even for an existing Qpid user, when switching from an 0-8/0-9 to 0-10 to 1.0 this approach IMO provides a more pain free strategy. Regards, Rajith > - Aidan > > -- > Apache Qpid - World Domination through Advanced Message Queueing > http://qpid.apache.org > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > > - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: AMQP 1.0
On Thu, Mar 19, 2009 at 1:29 PM, Rajith Attapattu wrote: > On Thu, Mar 19, 2009 at 6:36 AM, Aidan Skinner wrote: >> On Wed, Mar 18, 2009 at 8:26 PM, Gordon Sim wrote: >> The Java client uses JMS for this to an extent, but we still need a >> way of exposing AMQP specific things in ways that are as version >> independent as possible (such as the mandatory flag). I've been >> kicking around the idea of something like this: >> > > I am of the opinion that you could get 99% of the AMQP stuff while > still using pure JMS. > I have a few ideas around how to do the immediate flag etc while still > using pure JMS. > One such idea is to pass in a QPID specific property in the message > called "AMQP_IMMEDIATE" and the respective sender method can look for > the presense of this flag and put that in the delivery props. When See, I'm not sure this is really "pure JMS". It may not use any non-JMS API, but it does rely on non-JMS semantics. I can easily see that this improves portability from a "does my code compile" PoV. I think it may be quite unhelpful from a "does my code still work" PoV however. Having non-JMS features available as non-JMS API at least makes their dependence on this more obvious. - Aidan -- Apache Qpid - World Domination through Advanced Message Queueing http://qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: AMQP 1.0
On Thu, Mar 19, 2009 at 1:13 PM, Robert Godfrey wrote: > 2009/3/19 Aidan Skinner : >> On Wed, Mar 18, 2009 at 8:26 PM, Gordon Sim wrote: >> >>> I think, as has been discussed on this list recently, that getting some >>> higher level, protocol-independent APIs for those languages that don't >>> currently have them is a necessary first step and one that will be valuable >>> regardless. >> >> I think this is going to be really helpful for client applications, >> most of which don't really want to be tied to protocol versions. >> >> The Java client uses JMS for this to an extent, but we still need a >> way of exposing AMQP specific things in ways that are as version >> independent as possible (such as the mandatory flag). I've been >> kicking around the idea of something like this: > I think that we may find that from a Java/JMS perspective the more > profitable route will be to separate out a 1.0 implementation from the Are you talking about the interfaces here, or at a deeper level? That's sort of how 0-10 and 0-9/0-8 are implemented in the client currently, and I'm not convinced that the cut-n-shunt model works all that well. It may just be a matter of the process that occured there though, and with some refcatoring could well be the way to go. > legacy code. Defining an AMQSession interface which exposes AMQP > (1-0) semantics is still my preferred mechanism. I'm unsure whether > such an interface would have any direct relationship to JMS Session > however. It would seem sensible for the JMSSession to sit on top of AMQSession and then dispatch on the type of the session where it needs to do something different for earlier AMQP versions. I'm not sure how much backward compatibility we need to provide for existing users who are accessing the AMQP extensions. We've made some effort to do so so far, but the move to 1-0 may present a good opportunity and reason for breaking API compatibility. We'd only get one chance at this for a while though, so we'd need to get it right. >> There are still some significant details to work out, particularly >> around administration and translating messages from one protocol >> version to another. Clearly nirvana here is for a 0-8 client to be >> able to connect, send a message and have it go to 0-9, 0-10 and 1-0 >> clients and it Just Works. Similarly, persistence plugins shouldn't >> have to care about the type of message that they get - they should be >> able to persist any of them. > > Once we have completed the core of the AMQP1-0 specification then > myself, Rafi, John and others from the AMQP Working Group will be > working on documenting such things as > > * How to map JMS to AMQP in a portable way, > * How to send AMQP0-8/0-9/0-10 Messages ove AMQP1-0 Networks, and > * How to emulate the behaviour of exchanges using Links and Queues Those would be Really Helpful, particularly the first two if we're going to have meaningful interop with other AMQP vendors. - Aidan -- Apache Qpid - World Domination through Advanced Message Queueing http://qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: AMQP 1.0
On Thu, Mar 19, 2009 at 6:36 AM, Aidan Skinner wrote: > On Wed, Mar 18, 2009 at 8:26 PM, Gordon Sim wrote: > >> I think, as has been discussed on this list recently, that getting some >> higher level, protocol-independent APIs for those languages that don't >> currently have them is a necessary first step and one that will be valuable >> regardless. > > I think this is going to be really helpful for client applications, > most of which don't really want to be tied to protocol versions. > > The Java client uses JMS for this to an extent, but we still need a > way of exposing AMQP specific things in ways that are as version > independent as possible (such as the mandatory flag). I've been > kicking around the idea of something like this: > I am of the opinion that you could get 99% of the AMQP stuff while still using pure JMS. I have a few ideas around how to do the immediate flag etc while still using pure JMS. One such idea is to pass in a QPID specific property in the message called "AMQP_IMMEDIATE" and the respective sender method can look for the presense of this flag and put that in the delivery props. When using properties like this we don't have to worry about a specific AMQP version, as the respective delegate (ex BasicMessageProducer_0_10 in this instance) will know which flags to look and anything else can be ignored. I am currently working on a prototype to see how best we can use queue declare and binding arguments when defining our destinations, so we don't have to use anything non JMS. So I believe a fair bit can be done while still using pure JMS. > JMSSession -> AMQSession -> AMQ_[ver]_session > > With only things that are supported by all version fo AMQP in > AMQSession. This does lead to a couple of problems though, such as > features that are in all but one version of spec. > > The other option I was considering was something like > > JMSSession -> AMQSession -> AMQPre10Session -> AMQ010Session > > but I think that may be over engineering for the sake of over engineering. I think the current way of having a version specific delegate seems to have worked well. AMQSession (JMS Session) --> AMQ_version_specific_delegate. But of course I am always open to better ideas. Regards, Rajith - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: AMQP 1.0
2009/3/19 Aidan Skinner : > On Wed, Mar 18, 2009 at 8:26 PM, Gordon Sim wrote: > >> I think, as has been discussed on this list recently, that getting some >> higher level, protocol-independent APIs for those languages that don't >> currently have them is a necessary first step and one that will be valuable >> regardless. > > I think this is going to be really helpful for client applications, > most of which don't really want to be tied to protocol versions. > > The Java client uses JMS for this to an extent, but we still need a > way of exposing AMQP specific things in ways that are as version > independent as possible (such as the mandatory flag). I've been > kicking around the idea of something like this: > > JMSSession -> AMQSession -> AMQ_[ver]_session > > With only things that are supported by all version fo AMQP in > AMQSession. This does lead to a couple of problems though, such as > features that are in all but one version of spec. > > The other option I was considering was something like > > JMSSession -> AMQSession -> AMQPre10Session -> AMQ010Session > > but I think that may be over engineering for the sake of over engineering. I think that we may find that from a Java/JMS perspective the more profitable route will be to separate out a 1.0 implementation from the legacy code. Defining an AMQSession interface which exposes AMQP (1-0) semantics is still my preferred mechanism. I'm unsure whether such an interface would have any direct relationship to JMS Session however. > >> The broker has some limited support for multiple protocols at present, but >> they are really the remnants of upgrading from 0-9 'wip' to one version of >> 0-10 and then onto the final 0-10 without breaking the build and test >> suites. I think some thinking and design around improving that in general >> terms would also be a valuable step forwards. > > The java server supports 0-8 and 0-9, but they're really additional > protocol dialects. 0-10 and, in particular, 1-0 have somewhat more > substantial semantic differences. In order to properly support them I > think they key is to have as modular a server as possible. > > I've written up some of the improvements to the java server I think > should be made here: > http://qpid.apache.org/java-broker-modularisation.html (that page > needs to be updated a little since some of the works been done in > 0.5). > > The idea is that the core of the server does the basic work of taking > a message, putting it on disk, putting on a queue, taking it from a > queue and giving it to the client. The details of that, such as how > what message goes on what queue before being delivered to a consumer > and the protocol used to transfer messages, are implemented by 1 or > more plugins which contribute queues, protocol packs, admin wiring > etc. > > There are still some significant details to work out, particularly > around administration and translating messages from one protocol > version to another. Clearly nirvana here is for a 0-8 client to be > able to connect, send a message and have it go to 0-9, 0-10 and 1-0 > clients and it Just Works. Similarly, persistence plugins shouldn't > have to care about the type of message that they get - they should be > able to persist any of them. Once we have completed the core of the AMQP1-0 specification then myself, Rafi, John and others from the AMQP Working Group will be working on documenting such things as * How to map JMS to AMQP in a portable way, * How to send AMQP0-8/0-9/0-10 Messages ove AMQP1-0 Networks, and * How to emulate the behaviour of exchanges using Links and Queues Hope this helps, Rob - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-1758) Add AMQP options on queue.delete, queue.declare, exchange.declare in qpid-config
[ https://issues.apache.org/jira/browse/QPID-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683453#action_12683453 ] Ted Ross commented on QPID-1758: Thanks for the patch. One comment... The "--exclusive" option doesn't make a lot of sense for this utility so I've removed it from the patched file. This is because declaring a queue "exclusive" limits its use to the session that created it. In this case, it's qpid-config's session that creates the queue and that session is closed as soon as qpid-config exits. -Ted > Add AMQP options on queue.delete, queue.declare, exchange.declare in > qpid-config > > > Key: QPID-1758 > URL: https://issues.apache.org/jira/browse/QPID-1758 > Project: Qpid > Issue Type: Improvement > Components: python tools >Affects Versions: M4 >Reporter: Ffrench Mathilde >Assignee: Ted Ross >Priority: Trivial > Attachments: qpid-config.diff > > > Add some useful options to queue.delete, queue.declare, exchange.declare in > qpid-config : > queue.delete : if_unused and if_empty > queue.declare : alternate_exchange, passive, exclusive > exchange.declare : alternate_exchange, passive -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: AMQP 1.0
On Wed, Mar 18, 2009 at 8:26 PM, Gordon Sim wrote: > I think, as has been discussed on this list recently, that getting some > higher level, protocol-independent APIs for those languages that don't > currently have them is a necessary first step and one that will be valuable > regardless. I think this is going to be really helpful for client applications, most of which don't really want to be tied to protocol versions. The Java client uses JMS for this to an extent, but we still need a way of exposing AMQP specific things in ways that are as version independent as possible (such as the mandatory flag). I've been kicking around the idea of something like this: JMSSession -> AMQSession -> AMQ_[ver]_session With only things that are supported by all version fo AMQP in AMQSession. This does lead to a couple of problems though, such as features that are in all but one version of spec. The other option I was considering was something like JMSSession -> AMQSession -> AMQPre10Session -> AMQ010Session but I think that may be over engineering for the sake of over engineering. > The broker has some limited support for multiple protocols at present, but > they are really the remnants of upgrading from 0-9 'wip' to one version of > 0-10 and then onto the final 0-10 without breaking the build and test > suites. I think some thinking and design around improving that in general > terms would also be a valuable step forwards. The java server supports 0-8 and 0-9, but they're really additional protocol dialects. 0-10 and, in particular, 1-0 have somewhat more substantial semantic differences. In order to properly support them I think they key is to have as modular a server as possible. I've written up some of the improvements to the java server I think should be made here: http://qpid.apache.org/java-broker-modularisation.html (that page needs to be updated a little since some of the works been done in 0.5). The idea is that the core of the server does the basic work of taking a message, putting it on disk, putting on a queue, taking it from a queue and giving it to the client. The details of that, such as how what message goes on what queue before being delivered to a consumer and the protocol used to transfer messages, are implemented by 1 or more plugins which contribute queues, protocol packs, admin wiring etc. There are still some significant details to work out, particularly around administration and translating messages from one protocol version to another. Clearly nirvana here is for a 0-8 client to be able to connect, send a message and have it go to 0-9, 0-10 and 1-0 clients and it Just Works. Similarly, persistence plugins shouldn't have to care about the type of message that they get - they should be able to persist any of them. - Aidan -- Apache Qpid - World Domination through Advanced Message Queueing http://qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1758) Add AMQP options on queue.delete, queue.declare, exchange.declare in qpid-config
[ https://issues.apache.org/jira/browse/QPID-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ffrench Mathilde updated QPID-1758: --- Attachment: (was: qpid-config) > Add AMQP options on queue.delete, queue.declare, exchange.declare in > qpid-config > > > Key: QPID-1758 > URL: https://issues.apache.org/jira/browse/QPID-1758 > Project: Qpid > Issue Type: Improvement > Components: python tools >Affects Versions: M4 >Reporter: Ffrench Mathilde >Assignee: Ted Ross >Priority: Trivial > Attachments: qpid-config.diff > > > Add some useful options to queue.delete, queue.declare, exchange.declare in > qpid-config : > queue.delete : if_unused and if_empty > queue.declare : alternate_exchange, passive, exclusive > exchange.declare : alternate_exchange, passive -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1758) Add AMQP options on queue.delete, queue.declare, exchange.declare in qpid-config
[ https://issues.apache.org/jira/browse/QPID-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ffrench Mathilde updated QPID-1758: --- Attachment: qpid-config.diff diff of the patch > Add AMQP options on queue.delete, queue.declare, exchange.declare in > qpid-config > > > Key: QPID-1758 > URL: https://issues.apache.org/jira/browse/QPID-1758 > Project: Qpid > Issue Type: Improvement > Components: python tools >Affects Versions: M4 >Reporter: Ffrench Mathilde >Assignee: Ted Ross >Priority: Trivial > Attachments: qpid-config.diff > > > Add some useful options to queue.delete, queue.declare, exchange.declare in > qpid-config : > queue.delete : if_unused and if_empty > queue.declare : alternate_exchange, passive, exclusive > exchange.declare : alternate_exchange, passive -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1758) Add AMQP options on queue.delete, queue.declare, exchange.declare in qpid-config
[ https://issues.apache.org/jira/browse/QPID-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ffrench Mathilde updated QPID-1758: --- Description: Add some useful options to queue.delete, queue.declare, exchange.declare in qpid-config : queue.delete : if_unused and if_empty queue.declare : alternate_exchange, passive, exclusive exchange.declare : alternate_exchange, passive was: Add some useful options to queue.delete, queue.declare, exchange.declare in qpid-config : queue.delete : if_unused and if_empty queue.declare : alternate_exchange, passive, exclusive exchange.declare : alternate_exchange, passive, exclusive > Add AMQP options on queue.delete, queue.declare, exchange.declare in > qpid-config > > > Key: QPID-1758 > URL: https://issues.apache.org/jira/browse/QPID-1758 > Project: Qpid > Issue Type: Improvement > Components: python tools >Affects Versions: M4 >Reporter: Ffrench Mathilde >Assignee: Ted Ross >Priority: Trivial > Attachments: qpid-config > > > Add some useful options to queue.delete, queue.declare, exchange.declare in > qpid-config : > queue.delete : if_unused and if_empty > queue.declare : alternate_exchange, passive, exclusive > exchange.declare : alternate_exchange, passive -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: AMQP 1.0
James Mansion wrote: Gordon Sim wrote: Based on past experience I think its best to wait until the final spec is actually published before getting too concerned about an implementation plan. Its not long 'til then though - but I was actually more interested in what the process will be, and who will manage and execute it. For me the first part of the process is a protocol independent API and some thinking around how to support multiple protocols in the broker (allowing messages published over one protocol to be delivered over another etc). Another important aspect is ensuring that adding support for 1.0 doesn't break previously supported versions. Is this likely to be a 'show me the code' effort, or a 'show me the requirement, show me the plan, show me the design, show me the resourcing, show me the code' sort of thing? At the broadest level the requirement will be the 1.0 spec, obviously there may be parts that can be attacked incrementally adding support for optional or less commonly used features after the core is in place etc. I imagine that there will be some discussion nearer the time about how to break up the tasks and who does what. I suspect the details will vary by language and with the amount of interest shown. I myself plan to spend some time in the coming weeks thinking about the API question and will be posting my thoughts and comments to the list along with any patches that help explain the ideas. We have a great group of people on this list and the user list and hopefully we can all feed in ideas and get a very satisfactory result. We are now in the closing down stages of the 0.5 release. Ideally the next release will include a protocol independent API in all supported languages. Once that is out then hopefully the final 1.0 AMQP spec will have been published and steps towards that can be discussed. Qpid isn't entirely a 'spare time' project is it? Who does the heavy lifting? There are now many active commiters from different organisations (see http://cwiki.apache.org/confluence/display/qpid/People). (It *is* clearly spare time and 'for interest' for me - I've been playing while commuting and that won't change.) Thank you very much for investing your time in the project, it is great to have your interest! - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
