You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Kamran Saadatjoo <ka...@openflowsystems.com> on 2008/05/07 16:05:33 UTC
General question regarding Java QPID
I’m very new to QPID, so please forgive me if my question is trivial. I got
to know QPID because I was interested in the AMQP protocol. In going through
some of the examples (the Publisher.java and Subscriber.jave examples in the
Client pubsub directory in particular), I find that the AMQP methods are not
being used. Or maybe I don’t understand how they are being used. Is AMQP a
subset of QPID? If so, why would I use the AMQP classes verses JMS? Any
light shed on this trivial question is greatly appreciated.
Thank you.
Kamran Saadatjoo
Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.13/1375 - Release Date: 4/12/2008
11:32 AM
Re: General question regarding Java QPID
Posted by Aidan Skinner <ai...@apache.org>.
2008/5/7 Kamran Saadatjoo <ka...@openflowsystems.com>:
> I'm very new to QPID, so please forgive me if my question is trivial. I got
> to know QPID because I was interested in the AMQP protocol. In going through
> some of the examples (the Publisher.java and Subscriber.jave examples in the
> Client pubsub directory in particular), I find that the AMQP methods are not
> being used. Or maybe I don't understand how they are being used. Is AMQP a
> subset of QPID? If so, why would I use the AMQP classes verses JMS? Any
> light shed on this trivial question is greatly appreciated.
Qpid provides a library which implements the JMS API, and uses the
AMQP protocol on the wire to communicate with the broker. It is
possible to get at the AMQP specific methods by casting your Session
to an AMQPSession (for instance), but we don't reccomend that people
do this.
Let me know if you have any other questions.
- Aidan
--
aim/y!:aidans42 g:aidan.skinner@gmail.com
http://aidan.skinner.me.uk/
"We belong to nobody and nobody belongs to us. We don't even belong to
each other."
RE: General question regarding Java QPID
Posted by Kamran Saadatjoo <ka...@openflowsystems.com>.
Thanks very much. This is now very clear.
Kamran Saadatjoo
-----Original Message-----
From: Robert Greig [mailto:robert.j.greig@gmail.com]
Sent: Wednesday, May 07, 2008 3:43 PM
To: qpid-users@incubator.apache.org
Subject: Re: General question regarding Java QPID
2008/5/7 Kamran Saadatjoo <ka...@openflowsystems.com>:
> Robert: We're a very small group of old-timer mainframe programmers who
> would like to assemble a system of open source parts for the mainframe
> environment (z/OS) to work with old legacy data. Among other parts, the
> proposed system (which is in its infancy) will require a queuing
mechanism.
> In investigating the availability of non-proprietary queuing protocols, I
> came across AMQP, and then found my way to QPID. My basic requirement for
> this piece of the software is to have open source queuing software that I
> can run on z/OS.
OK, since z/OS has a good JVM and qpid has no native components (i.e.
no C++ or C accessed via JNI) you should be able to get qpid to work.
I am not aware of anyone getting qpid running on z/OS yet but if you
run into any difficulties or have any questions please do let us know
and we will do our best to help.
> I originally started with the C++ version of QPID, but decided to look at
> the Java version to see if I could minimize development cycle. That's
when
> my confusion with AMQP and JMS started. I'm very new to JMS as well, and
> don't know if it is a wrapper for other underlying, possibly proprietary
> products, or it is a complete queuing system on its own. One of our main
> goal is to minimize requirements for proprietary software.
Ah ok. Let me try to explain this.
JMS is a vendor-independent API for messaging in Java. Nearly every
messaging product that has a Java client implementation supports JMS.
That includes IBM MQ as well as the open source products (e.g. JBoss
Messaging).
JMS in itself is not a queuing system, it is just an API. Think of it
like ODBC - it isn't a database but an API to access a database.
I strongly recommend you use the Qpid JMS API. If you use it, you will
not be tied to Qpid plus you will be able to find examples all over
the web for JMS programs. Obviously I hope that you think Qpid is
great and meets all your needs but if you want to switch it should be
relatively simple if you stick to JMS.
You would have a similar choice if you picked IBM MQ - it has both a
"native" API and it supports JMS. The native API has been around for a
very long time whereas the JMS API is newer. Most development teams I
have worked with that use MQ now pick JMS to avoid being tied too
closely to MQ.
So one question you may have is "how does AMQP relate to JMS"? AMQP is
a wire level protocol, rather than an API. This means that you should
be able to have a mixture of AMQP compliant products in your
infrastructure and they will interoperate. This is independent of
whether they are java or C++ or python.
Let me know if you have further questions or if this isn't very clear.
Robert
Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.13/1375 - Release Date: 4/12/2008
11:32 AM
Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.13/1375 - Release Date: 4/12/2008
11:32 AM
Re: General question regarding Java QPID
Posted by Robert Greig <ro...@gmail.com>.
2008/5/7 Kamran Saadatjoo <ka...@openflowsystems.com>:
> Robert: We're a very small group of old-timer mainframe programmers who
> would like to assemble a system of open source parts for the mainframe
> environment (z/OS) to work with old legacy data. Among other parts, the
> proposed system (which is in its infancy) will require a queuing mechanism.
> In investigating the availability of non-proprietary queuing protocols, I
> came across AMQP, and then found my way to QPID. My basic requirement for
> this piece of the software is to have open source queuing software that I
> can run on z/OS.
OK, since z/OS has a good JVM and qpid has no native components (i.e.
no C++ or C accessed via JNI) you should be able to get qpid to work.
I am not aware of anyone getting qpid running on z/OS yet but if you
run into any difficulties or have any questions please do let us know
and we will do our best to help.
> I originally started with the C++ version of QPID, but decided to look at
> the Java version to see if I could minimize development cycle. That's when
> my confusion with AMQP and JMS started. I'm very new to JMS as well, and
> don't know if it is a wrapper for other underlying, possibly proprietary
> products, or it is a complete queuing system on its own. One of our main
> goal is to minimize requirements for proprietary software.
Ah ok. Let me try to explain this.
JMS is a vendor-independent API for messaging in Java. Nearly every
messaging product that has a Java client implementation supports JMS.
That includes IBM MQ as well as the open source products (e.g. JBoss
Messaging).
JMS in itself is not a queuing system, it is just an API. Think of it
like ODBC - it isn't a database but an API to access a database.
I strongly recommend you use the Qpid JMS API. If you use it, you will
not be tied to Qpid plus you will be able to find examples all over
the web for JMS programs. Obviously I hope that you think Qpid is
great and meets all your needs but if you want to switch it should be
relatively simple if you stick to JMS.
You would have a similar choice if you picked IBM MQ - it has both a
"native" API and it supports JMS. The native API has been around for a
very long time whereas the JMS API is newer. Most development teams I
have worked with that use MQ now pick JMS to avoid being tied too
closely to MQ.
So one question you may have is "how does AMQP relate to JMS"? AMQP is
a wire level protocol, rather than an API. This means that you should
be able to have a mixture of AMQP compliant products in your
infrastructure and they will interoperate. This is independent of
whether they are java or C++ or python.
Let me know if you have further questions or if this isn't very clear.
Robert
RE: General question regarding Java QPID
Posted by Kamran Saadatjoo <ka...@openflowsystems.com>.
Robert: We're a very small group of old-timer mainframe programmers who
would like to assemble a system of open source parts for the mainframe
environment (z/OS) to work with old legacy data. Among other parts, the
proposed system (which is in its infancy) will require a queuing mechanism.
In investigating the availability of non-proprietary queuing protocols, I
came across AMQP, and then found my way to QPID. My basic requirement for
this piece of the software is to have open source queuing software that I
can run on z/OS.
I originally started with the C++ version of QPID, but decided to look at
the Java version to see if I could minimize development cycle. That's when
my confusion with AMQP and JMS started. I'm very new to JMS as well, and
don’t know if it is a wrapper for other underlying, possibly proprietary
products, or it is a complete queuing system on its own. One of our main
goal is to minimize requirements for proprietary software.
Once again, thank you for your help.
Kamran Saadatjoo
Open Flow Systems, Inc.
404-247-0454 (Cell)
-----Original Message-----
From: Robert Greig [mailto:robert.j.greig@gmail.com]
Sent: Wednesday, May 07, 2008 10:40 AM
To: qpid-users@incubator.apache.org
Subject: Re: General question regarding Java QPID
2008/5/7 Shahbaz Chaudhary <sc...@marcopolonetwork.com>:
> Hi, I also started testing with the QPid version of the stack (rather
> than the Red hat mrg) because Qpid has a non-jms Java api.
On trunk (i.e. not yet a released version) there is a non-JMS low level API.
> I was hoping to avoid JMS entirely, it sounds like the standard and the
> expected practice is actually to use JMS for java based projects rather
> than the AMQP specific api?
So far, we have found that almost all our users want a JMS API since
most people are either migrating from another JMS product or are
familiar with JMS due to its ubiquity. Things like Mule or Spring work
out of the box with Qpid for example because it is JMS compliant.
However, it may be that some people want to interact directly at the
protocol level and that was the motivation for having another API.
I would be very interested to know your reasons for wanting to avoid
JMS and also, if you can share it, what your use case is. This is so
that we can make sure we address all your requirements in the next
release(s). The people who have worked on the low level API can also
perhaps help out here.
Thanks,
Robert
Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.13/1375 - Release Date: 4/12/2008
11:32 AM
Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.13/1375 - Release Date: 4/12/2008
11:32 AM
RE: General question regarding Java QPID
Posted by Kamran Saadatjoo <ka...@openflowsystems.com>.
Perfect. Thank you.
Kamran Saadatjoo
-----Original Message-----
From: Shahbaz Chaudhary [mailto:schaudhary@marcopolonetwork.com]
Sent: Friday, May 09, 2008 10:32 AM
To: qpid-users@incubator.apache.org
Subject: RE: General question regarding Java QPID
I have the svn version. I initially tried the Red Hat mrg version, but
they don't have the AMQ examples yet. The same could be true of QPid's
release downloads. The svn version also has .NET examples, which, I
don't believe are in the release download.
(svn co http://svn.apache.org/repos/asf/incubator/qpid/trunk)
However, it sounds like I should be getting the JMS version running.
Shahbaz Chaudhary
-----Original Message-----
From: Kamran Saadatjoo [mailto:kamran@openflowsystems.com]
Sent: Friday, May 09, 2008 10:23 AM
To: qpid-users@incubator.apache.org
Subject: RE: General question regarding Java QPID
Thanks for this Shabaz: I don't seem to have the amqpexample
subdirectory. I
might have done something wrong when I uncompressed the source. I'll
look
around and see if I can locate it. Thanks again.
Kamran Saadatjoo
Open Flow Systems, Inc.
404-247-0454 (Cell)
-----Original Message-----
From: Shahbaz Chaudhary [mailto:schaudhary@marcopolonetwork.com]
Sent: Friday, May 09, 2008 10:11 AM
To: qpid-users@incubator.apache.org
Subject: RE: General question regarding Java QPID
Kamran,
I believe JMS examples have their non-jms counterparts in the following
directory:
qpid/java/client/example/src/main/java/org/apache/qpid/example/amqpexamp
le
Shahbaz Chaudhary
-----Original Message-----
From: Kamran Saadatjoo [mailto:kamran@openflowsystems.com]
Sent: Friday, May 09, 2008 8:00 AM
To: qpid-users@incubator.apache.org
Subject: RE: General question regarding Java QPID
For me, a couple of non-JMS AMQP examples would really be nice to have.
I
can map the C++ version to the AMQP documentation, but cannot do the
same
here. I'm sure a lot of my difficulties stem from my own inexperience,
but
if anyone can direct me to some non-JMS AMQP examples, I would be
grateful.
Kamran Saadatjoo
-----Original Message-----
From: Rajith Attapattu [mailto:rajith77@gmail.com]
Sent: Thursday, May 08, 2008 10:13 PM
To: qpid-users@incubator.apache.org
Subject: Re: General question regarding Java QPID
On Thu, May 8, 2008 at 2:25 PM, Robert Greig <ro...@gmail.com>
wrote:
> 2008/5/8 Shahbaz Chaudhary <sc...@marcopolonetwork.com>:
> > I am interested in a non-jms api, frankly, for some silly reasons.
>
> Well, I don't think your reasons are silly. I have heard these things
> several times, so let me give you my perspective.
I second that, we have heard this from several folks.
>
>
> > have never gotten used to Java's (J2EE's actually) InitialContext,
JNDI,
> > various configuration files, etc.
>
> The initial context is one bit that does tend to change from vendor to
> vendor so I agree it can be awkward. However I would argue that Qpid's
> implementation makes this as simple to use as possible - you basically
> need one properties file into which you can put the configuration. Or
> alternatively, of course, you do not need to use JNDI at all - you can
> construct AMQConnection objects.
>
> I would recommend the Qpid properties file configuration personally,
> since you inevitably want to put the configuration somewhere outside
> of your code.
>
> With Qpid you do not need any external JNDI server (unless you choose
> to use one of course).
As Rob mentioned the Qpid properties file is a nice way to get the JNDI
without having to mess up with external JNDI servers or any JEE
nonsence.
Some of the recent additions I did makes it possible to configure
destinations with any exchange/routing key pair.
I am planning to add more documentation on this aspect.
>
> > I also expect that the AMQP library to be faster and possibly
better
> > typed--so I don't deal with generic onMessage(Message) or
> > onMessage(Object), etc. functions ('generic' being used here as
normal
> > English, not as Java's Generics)
>
> I don't think that an AMQP library would be faster in most cases. The
> way it is implemented, JMS does not add much overhead on the client.
> There are of course certain cases where it could be faster I grant you
> but I'd have to think a bit about that. Maybe others can jump in if
> they see any specific scenarios?
For most cases JMS should be fast and good enough.
The JMS consumer side will have one extra thread for dispatching which
you
can avoid if you write your own stuff using the AMQP API.
But frankly the JMS implementation does take care of most of the grunt
work
for you, so you could work at a fairly abstract level.
So unless you have a very compelling reason, it's good to use the JMS
API.
Some of the reasons for using the AMQP API directly would be,
===============================================
You want to dynamically create/delete exchanges/queues/bindings as part
of
the application logic.
The JMS API works well if you pre create your exchange/queues/bindings
using
the JNDI properties file.
If your application needs to query for different exchanges, bindings,
queues
etc as part of your application logic then you would need to use the
AMQP
API
If you want to have very fine grain flow controlling. The JMS impl deals
with only message units and use window mode (however we should make the
byte
units configurable). If your application needs to switch between the
different flow control modes and/or change byte/message credits
dynamically
as part of application logic then using the AMQP API makes sense.
If you want fairly low level functionality. Ex If you want to write an
intermediary that only looks at certain message properties or delivery
properties or if you want to write some sort of intermediary that
transforms
messages, then it would be a lot more efficient to use the low level
API.
If your application is extreamly sensitive to latencies etc then you may
wanna use the low level API to have a very tightly coupled
implementation
with your application where you can try to optimize it heavily for your
use.
Another reason would be if you are running on a Realtime java JVM you
can
use the low level API and build your functionality using Realtime
constructs
such as RealTimeThreads, NoHeapRealTimeThreads and using the fancy
memory
model for appropriately partitioning your object in importal and scope
memory. You can also write your own IO model using real time constructs
as
it is pluggable in the current code.
>
> In terms of the typing, how would you like the API to look? We could
> possibly integrate any good ideas you have into our extended JMS API.
>
> > I am a single developer here who needs to quickly set up the broker
and
> > start publishing/subscribing to data. All my development is new.
I
> > need to deal with financial data, which means as low latency as
> > possible.
>
> I work for a tier one investment bank, in the front office - if you
> want, you can search for me on linkedin.com to see what I do. So high
> throughput and low latency are key requirements for me as well.
>
> It should be possible to get qpid running very quickly indeed -
> literally unzip the broker and it should work out of the box without
> any special configuration. People have been doing some work on our
> docs recently (it is something getting a lot of attention) so do let
> us know if anything is unclear or does not work as expected.
>
> Robert
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.13/1375 - Release Date:
4/12/2008
11:32 AM
Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.13/1375 - Release Date:
4/12/2008
11:32 AM
Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.13/1375 - Release Date:
4/12/2008
11:32 AM
Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.13/1375 - Release Date:
4/12/2008
11:32 AM
Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.13/1375 - Release Date: 4/12/2008
11:32 AM
Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.13/1375 - Release Date: 4/12/2008
11:32 AM
RE: General question regarding Java QPID
Posted by Shahbaz Chaudhary <sc...@marcopolonetwork.com>.
I have the svn version. I initially tried the Red Hat mrg version, but
they don't have the AMQ examples yet. The same could be true of QPid's
release downloads. The svn version also has .NET examples, which, I
don't believe are in the release download.
(svn co http://svn.apache.org/repos/asf/incubator/qpid/trunk)
However, it sounds like I should be getting the JMS version running.
Shahbaz Chaudhary
-----Original Message-----
From: Kamran Saadatjoo [mailto:kamran@openflowsystems.com]
Sent: Friday, May 09, 2008 10:23 AM
To: qpid-users@incubator.apache.org
Subject: RE: General question regarding Java QPID
Thanks for this Shabaz: I don't seem to have the amqpexample
subdirectory. I
might have done something wrong when I uncompressed the source. I'll
look
around and see if I can locate it. Thanks again.
Kamran Saadatjoo
Open Flow Systems, Inc.
404-247-0454 (Cell)
-----Original Message-----
From: Shahbaz Chaudhary [mailto:schaudhary@marcopolonetwork.com]
Sent: Friday, May 09, 2008 10:11 AM
To: qpid-users@incubator.apache.org
Subject: RE: General question regarding Java QPID
Kamran,
I believe JMS examples have their non-jms counterparts in the following
directory:
qpid/java/client/example/src/main/java/org/apache/qpid/example/amqpexamp
le
Shahbaz Chaudhary
-----Original Message-----
From: Kamran Saadatjoo [mailto:kamran@openflowsystems.com]
Sent: Friday, May 09, 2008 8:00 AM
To: qpid-users@incubator.apache.org
Subject: RE: General question regarding Java QPID
For me, a couple of non-JMS AMQP examples would really be nice to have.
I
can map the C++ version to the AMQP documentation, but cannot do the
same
here. I'm sure a lot of my difficulties stem from my own inexperience,
but
if anyone can direct me to some non-JMS AMQP examples, I would be
grateful.
Kamran Saadatjoo
-----Original Message-----
From: Rajith Attapattu [mailto:rajith77@gmail.com]
Sent: Thursday, May 08, 2008 10:13 PM
To: qpid-users@incubator.apache.org
Subject: Re: General question regarding Java QPID
On Thu, May 8, 2008 at 2:25 PM, Robert Greig <ro...@gmail.com>
wrote:
> 2008/5/8 Shahbaz Chaudhary <sc...@marcopolonetwork.com>:
> > I am interested in a non-jms api, frankly, for some silly reasons.
>
> Well, I don't think your reasons are silly. I have heard these things
> several times, so let me give you my perspective.
I second that, we have heard this from several folks.
>
>
> > have never gotten used to Java's (J2EE's actually) InitialContext,
JNDI,
> > various configuration files, etc.
>
> The initial context is one bit that does tend to change from vendor to
> vendor so I agree it can be awkward. However I would argue that Qpid's
> implementation makes this as simple to use as possible - you basically
> need one properties file into which you can put the configuration. Or
> alternatively, of course, you do not need to use JNDI at all - you can
> construct AMQConnection objects.
>
> I would recommend the Qpid properties file configuration personally,
> since you inevitably want to put the configuration somewhere outside
> of your code.
>
> With Qpid you do not need any external JNDI server (unless you choose
> to use one of course).
As Rob mentioned the Qpid properties file is a nice way to get the JNDI
without having to mess up with external JNDI servers or any JEE
nonsence.
Some of the recent additions I did makes it possible to configure
destinations with any exchange/routing key pair.
I am planning to add more documentation on this aspect.
>
> > I also expect that the AMQP library to be faster and possibly
better
> > typed--so I don't deal with generic onMessage(Message) or
> > onMessage(Object), etc. functions ('generic' being used here as
normal
> > English, not as Java's Generics)
>
> I don't think that an AMQP library would be faster in most cases. The
> way it is implemented, JMS does not add much overhead on the client.
> There are of course certain cases where it could be faster I grant you
> but I'd have to think a bit about that. Maybe others can jump in if
> they see any specific scenarios?
For most cases JMS should be fast and good enough.
The JMS consumer side will have one extra thread for dispatching which
you
can avoid if you write your own stuff using the AMQP API.
But frankly the JMS implementation does take care of most of the grunt
work
for you, so you could work at a fairly abstract level.
So unless you have a very compelling reason, it's good to use the JMS
API.
Some of the reasons for using the AMQP API directly would be,
===============================================
You want to dynamically create/delete exchanges/queues/bindings as part
of
the application logic.
The JMS API works well if you pre create your exchange/queues/bindings
using
the JNDI properties file.
If your application needs to query for different exchanges, bindings,
queues
etc as part of your application logic then you would need to use the
AMQP
API
If you want to have very fine grain flow controlling. The JMS impl deals
with only message units and use window mode (however we should make the
byte
units configurable). If your application needs to switch between the
different flow control modes and/or change byte/message credits
dynamically
as part of application logic then using the AMQP API makes sense.
If you want fairly low level functionality. Ex If you want to write an
intermediary that only looks at certain message properties or delivery
properties or if you want to write some sort of intermediary that
transforms
messages, then it would be a lot more efficient to use the low level
API.
If your application is extreamly sensitive to latencies etc then you may
wanna use the low level API to have a very tightly coupled
implementation
with your application where you can try to optimize it heavily for your
use.
Another reason would be if you are running on a Realtime java JVM you
can
use the low level API and build your functionality using Realtime
constructs
such as RealTimeThreads, NoHeapRealTimeThreads and using the fancy
memory
model for appropriately partitioning your object in importal and scope
memory. You can also write your own IO model using real time constructs
as
it is pluggable in the current code.
>
> In terms of the typing, how would you like the API to look? We could
> possibly integrate any good ideas you have into our extended JMS API.
>
> > I am a single developer here who needs to quickly set up the broker
and
> > start publishing/subscribing to data. All my development is new.
I
> > need to deal with financial data, which means as low latency as
> > possible.
>
> I work for a tier one investment bank, in the front office - if you
> want, you can search for me on linkedin.com to see what I do. So high
> throughput and low latency are key requirements for me as well.
>
> It should be possible to get qpid running very quickly indeed -
> literally unzip the broker and it should work out of the box without
> any special configuration. People have been doing some work on our
> docs recently (it is something getting a lot of attention) so do let
> us know if anything is unclear or does not work as expected.
>
> Robert
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.13/1375 - Release Date:
4/12/2008
11:32 AM
Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.13/1375 - Release Date:
4/12/2008
11:32 AM
Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.13/1375 - Release Date:
4/12/2008
11:32 AM
Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.13/1375 - Release Date:
4/12/2008
11:32 AM
RE: General question regarding Java QPID
Posted by Kamran Saadatjoo <ka...@openflowsystems.com>.
Thanks for this Shabaz: I don’t seem to have the amqpexample subdirectory. I
might have done something wrong when I uncompressed the source. I'll look
around and see if I can locate it. Thanks again.
Kamran Saadatjoo
Open Flow Systems, Inc.
404-247-0454 (Cell)
-----Original Message-----
From: Shahbaz Chaudhary [mailto:schaudhary@marcopolonetwork.com]
Sent: Friday, May 09, 2008 10:11 AM
To: qpid-users@incubator.apache.org
Subject: RE: General question regarding Java QPID
Kamran,
I believe JMS examples have their non-jms counterparts in the following
directory:
qpid/java/client/example/src/main/java/org/apache/qpid/example/amqpexamp
le
Shahbaz Chaudhary
-----Original Message-----
From: Kamran Saadatjoo [mailto:kamran@openflowsystems.com]
Sent: Friday, May 09, 2008 8:00 AM
To: qpid-users@incubator.apache.org
Subject: RE: General question regarding Java QPID
For me, a couple of non-JMS AMQP examples would really be nice to have.
I
can map the C++ version to the AMQP documentation, but cannot do the
same
here. I'm sure a lot of my difficulties stem from my own inexperience,
but
if anyone can direct me to some non-JMS AMQP examples, I would be
grateful.
Kamran Saadatjoo
-----Original Message-----
From: Rajith Attapattu [mailto:rajith77@gmail.com]
Sent: Thursday, May 08, 2008 10:13 PM
To: qpid-users@incubator.apache.org
Subject: Re: General question regarding Java QPID
On Thu, May 8, 2008 at 2:25 PM, Robert Greig <ro...@gmail.com>
wrote:
> 2008/5/8 Shahbaz Chaudhary <sc...@marcopolonetwork.com>:
> > I am interested in a non-jms api, frankly, for some silly reasons.
>
> Well, I don't think your reasons are silly. I have heard these things
> several times, so let me give you my perspective.
I second that, we have heard this from several folks.
>
>
> > have never gotten used to Java's (J2EE's actually) InitialContext,
JNDI,
> > various configuration files, etc.
>
> The initial context is one bit that does tend to change from vendor to
> vendor so I agree it can be awkward. However I would argue that Qpid's
> implementation makes this as simple to use as possible - you basically
> need one properties file into which you can put the configuration. Or
> alternatively, of course, you do not need to use JNDI at all - you can
> construct AMQConnection objects.
>
> I would recommend the Qpid properties file configuration personally,
> since you inevitably want to put the configuration somewhere outside
> of your code.
>
> With Qpid you do not need any external JNDI server (unless you choose
> to use one of course).
As Rob mentioned the Qpid properties file is a nice way to get the JNDI
without having to mess up with external JNDI servers or any JEE
nonsence.
Some of the recent additions I did makes it possible to configure
destinations with any exchange/routing key pair.
I am planning to add more documentation on this aspect.
>
> > I also expect that the AMQP library to be faster and possibly
better
> > typed--so I don't deal with generic onMessage(Message) or
> > onMessage(Object), etc. functions ('generic' being used here as
normal
> > English, not as Java's Generics)
>
> I don't think that an AMQP library would be faster in most cases. The
> way it is implemented, JMS does not add much overhead on the client.
> There are of course certain cases where it could be faster I grant you
> but I'd have to think a bit about that. Maybe others can jump in if
> they see any specific scenarios?
For most cases JMS should be fast and good enough.
The JMS consumer side will have one extra thread for dispatching which
you
can avoid if you write your own stuff using the AMQP API.
But frankly the JMS implementation does take care of most of the grunt
work
for you, so you could work at a fairly abstract level.
So unless you have a very compelling reason, it's good to use the JMS
API.
Some of the reasons for using the AMQP API directly would be,
===============================================
You want to dynamically create/delete exchanges/queues/bindings as part
of
the application logic.
The JMS API works well if you pre create your exchange/queues/bindings
using
the JNDI properties file.
If your application needs to query for different exchanges, bindings,
queues
etc as part of your application logic then you would need to use the
AMQP
API
If you want to have very fine grain flow controlling. The JMS impl deals
with only message units and use window mode (however we should make the
byte
units configurable). If your application needs to switch between the
different flow control modes and/or change byte/message credits
dynamically
as part of application logic then using the AMQP API makes sense.
If you want fairly low level functionality. Ex If you want to write an
intermediary that only looks at certain message properties or delivery
properties or if you want to write some sort of intermediary that
transforms
messages, then it would be a lot more efficient to use the low level
API.
If your application is extreamly sensitive to latencies etc then you may
wanna use the low level API to have a very tightly coupled
implementation
with your application where you can try to optimize it heavily for your
use.
Another reason would be if you are running on a Realtime java JVM you
can
use the low level API and build your functionality using Realtime
constructs
such as RealTimeThreads, NoHeapRealTimeThreads and using the fancy
memory
model for appropriately partitioning your object in importal and scope
memory. You can also write your own IO model using real time constructs
as
it is pluggable in the current code.
>
> In terms of the typing, how would you like the API to look? We could
> possibly integrate any good ideas you have into our extended JMS API.
>
> > I am a single developer here who needs to quickly set up the broker
and
> > start publishing/subscribing to data. All my development is new.
I
> > need to deal with financial data, which means as low latency as
> > possible.
>
> I work for a tier one investment bank, in the front office - if you
> want, you can search for me on linkedin.com to see what I do. So high
> throughput and low latency are key requirements for me as well.
>
> It should be possible to get qpid running very quickly indeed -
> literally unzip the broker and it should work out of the box without
> any special configuration. People have been doing some work on our
> docs recently (it is something getting a lot of attention) so do let
> us know if anything is unclear or does not work as expected.
>
> Robert
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.13/1375 - Release Date:
4/12/2008
11:32 AM
Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.13/1375 - Release Date:
4/12/2008
11:32 AM
Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.13/1375 - Release Date: 4/12/2008
11:32 AM
Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.13/1375 - Release Date: 4/12/2008
11:32 AM
RE: General question regarding Java QPID
Posted by Shahbaz Chaudhary <sc...@marcopolonetwork.com>.
Kamran,
I believe JMS examples have their non-jms counterparts in the following
directory:
qpid/java/client/example/src/main/java/org/apache/qpid/example/amqpexamp
le
Shahbaz Chaudhary
-----Original Message-----
From: Kamran Saadatjoo [mailto:kamran@openflowsystems.com]
Sent: Friday, May 09, 2008 8:00 AM
To: qpid-users@incubator.apache.org
Subject: RE: General question regarding Java QPID
For me, a couple of non-JMS AMQP examples would really be nice to have.
I
can map the C++ version to the AMQP documentation, but cannot do the
same
here. I'm sure a lot of my difficulties stem from my own inexperience,
but
if anyone can direct me to some non-JMS AMQP examples, I would be
grateful.
Kamran Saadatjoo
-----Original Message-----
From: Rajith Attapattu [mailto:rajith77@gmail.com]
Sent: Thursday, May 08, 2008 10:13 PM
To: qpid-users@incubator.apache.org
Subject: Re: General question regarding Java QPID
On Thu, May 8, 2008 at 2:25 PM, Robert Greig <ro...@gmail.com>
wrote:
> 2008/5/8 Shahbaz Chaudhary <sc...@marcopolonetwork.com>:
> > I am interested in a non-jms api, frankly, for some silly reasons.
>
> Well, I don't think your reasons are silly. I have heard these things
> several times, so let me give you my perspective.
I second that, we have heard this from several folks.
>
>
> > have never gotten used to Java's (J2EE's actually) InitialContext,
JNDI,
> > various configuration files, etc.
>
> The initial context is one bit that does tend to change from vendor to
> vendor so I agree it can be awkward. However I would argue that Qpid's
> implementation makes this as simple to use as possible - you basically
> need one properties file into which you can put the configuration. Or
> alternatively, of course, you do not need to use JNDI at all - you can
> construct AMQConnection objects.
>
> I would recommend the Qpid properties file configuration personally,
> since you inevitably want to put the configuration somewhere outside
> of your code.
>
> With Qpid you do not need any external JNDI server (unless you choose
> to use one of course).
As Rob mentioned the Qpid properties file is a nice way to get the JNDI
without having to mess up with external JNDI servers or any JEE
nonsence.
Some of the recent additions I did makes it possible to configure
destinations with any exchange/routing key pair.
I am planning to add more documentation on this aspect.
>
> > I also expect that the AMQP library to be faster and possibly
better
> > typed--so I don't deal with generic onMessage(Message) or
> > onMessage(Object), etc. functions ('generic' being used here as
normal
> > English, not as Java's Generics)
>
> I don't think that an AMQP library would be faster in most cases. The
> way it is implemented, JMS does not add much overhead on the client.
> There are of course certain cases where it could be faster I grant you
> but I'd have to think a bit about that. Maybe others can jump in if
> they see any specific scenarios?
For most cases JMS should be fast and good enough.
The JMS consumer side will have one extra thread for dispatching which
you
can avoid if you write your own stuff using the AMQP API.
But frankly the JMS implementation does take care of most of the grunt
work
for you, so you could work at a fairly abstract level.
So unless you have a very compelling reason, it's good to use the JMS
API.
Some of the reasons for using the AMQP API directly would be,
===============================================
You want to dynamically create/delete exchanges/queues/bindings as part
of
the application logic.
The JMS API works well if you pre create your exchange/queues/bindings
using
the JNDI properties file.
If your application needs to query for different exchanges, bindings,
queues
etc as part of your application logic then you would need to use the
AMQP
API
If you want to have very fine grain flow controlling. The JMS impl deals
with only message units and use window mode (however we should make the
byte
units configurable). If your application needs to switch between the
different flow control modes and/or change byte/message credits
dynamically
as part of application logic then using the AMQP API makes sense.
If you want fairly low level functionality. Ex If you want to write an
intermediary that only looks at certain message properties or delivery
properties or if you want to write some sort of intermediary that
transforms
messages, then it would be a lot more efficient to use the low level
API.
If your application is extreamly sensitive to latencies etc then you may
wanna use the low level API to have a very tightly coupled
implementation
with your application where you can try to optimize it heavily for your
use.
Another reason would be if you are running on a Realtime java JVM you
can
use the low level API and build your functionality using Realtime
constructs
such as RealTimeThreads, NoHeapRealTimeThreads and using the fancy
memory
model for appropriately partitioning your object in importal and scope
memory. You can also write your own IO model using real time constructs
as
it is pluggable in the current code.
>
> In terms of the typing, how would you like the API to look? We could
> possibly integrate any good ideas you have into our extended JMS API.
>
> > I am a single developer here who needs to quickly set up the broker
and
> > start publishing/subscribing to data. All my development is new.
I
> > need to deal with financial data, which means as low latency as
> > possible.
>
> I work for a tier one investment bank, in the front office - if you
> want, you can search for me on linkedin.com to see what I do. So high
> throughput and low latency are key requirements for me as well.
>
> It should be possible to get qpid running very quickly indeed -
> literally unzip the broker and it should work out of the box without
> any special configuration. People have been doing some work on our
> docs recently (it is something getting a lot of attention) so do let
> us know if anything is unclear or does not work as expected.
>
> Robert
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.13/1375 - Release Date:
4/12/2008
11:32 AM
Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.13/1375 - Release Date:
4/12/2008
11:32 AM
RE: General question regarding Java QPID
Posted by Kamran Saadatjoo <ka...@openflowsystems.com>.
For me, a couple of non-JMS AMQP examples would really be nice to have. I
can map the C++ version to the AMQP documentation, but cannot do the same
here. I'm sure a lot of my difficulties stem from my own inexperience, but
if anyone can direct me to some non-JMS AMQP examples, I would be grateful.
Kamran Saadatjoo
-----Original Message-----
From: Rajith Attapattu [mailto:rajith77@gmail.com]
Sent: Thursday, May 08, 2008 10:13 PM
To: qpid-users@incubator.apache.org
Subject: Re: General question regarding Java QPID
On Thu, May 8, 2008 at 2:25 PM, Robert Greig <ro...@gmail.com>
wrote:
> 2008/5/8 Shahbaz Chaudhary <sc...@marcopolonetwork.com>:
> > I am interested in a non-jms api, frankly, for some silly reasons.
>
> Well, I don't think your reasons are silly. I have heard these things
> several times, so let me give you my perspective.
I second that, we have heard this from several folks.
>
>
> > have never gotten used to Java's (J2EE's actually) InitialContext,
JNDI,
> > various configuration files, etc.
>
> The initial context is one bit that does tend to change from vendor to
> vendor so I agree it can be awkward. However I would argue that Qpid's
> implementation makes this as simple to use as possible - you basically
> need one properties file into which you can put the configuration. Or
> alternatively, of course, you do not need to use JNDI at all - you can
> construct AMQConnection objects.
>
> I would recommend the Qpid properties file configuration personally,
> since you inevitably want to put the configuration somewhere outside
> of your code.
>
> With Qpid you do not need any external JNDI server (unless you choose
> to use one of course).
As Rob mentioned the Qpid properties file is a nice way to get the JNDI
without having to mess up with external JNDI servers or any JEE nonsence.
Some of the recent additions I did makes it possible to configure
destinations with any exchange/routing key pair.
I am planning to add more documentation on this aspect.
>
> > I also expect that the AMQP library to be faster and possibly better
> > typed--so I don't deal with generic onMessage(Message) or
> > onMessage(Object), etc. functions ('generic' being used here as normal
> > English, not as Java's Generics)
>
> I don't think that an AMQP library would be faster in most cases. The
> way it is implemented, JMS does not add much overhead on the client.
> There are of course certain cases where it could be faster I grant you
> but I'd have to think a bit about that. Maybe others can jump in if
> they see any specific scenarios?
For most cases JMS should be fast and good enough.
The JMS consumer side will have one extra thread for dispatching which you
can avoid if you write your own stuff using the AMQP API.
But frankly the JMS implementation does take care of most of the grunt work
for you, so you could work at a fairly abstract level.
So unless you have a very compelling reason, it's good to use the JMS API.
Some of the reasons for using the AMQP API directly would be,
===============================================
You want to dynamically create/delete exchanges/queues/bindings as part of
the application logic.
The JMS API works well if you pre create your exchange/queues/bindings using
the JNDI properties file.
If your application needs to query for different exchanges, bindings, queues
etc as part of your application logic then you would need to use the AMQP
API
If you want to have very fine grain flow controlling. The JMS impl deals
with only message units and use window mode (however we should make the byte
units configurable). If your application needs to switch between the
different flow control modes and/or change byte/message credits dynamically
as part of application logic then using the AMQP API makes sense.
If you want fairly low level functionality. Ex If you want to write an
intermediary that only looks at certain message properties or delivery
properties or if you want to write some sort of intermediary that transforms
messages, then it would be a lot more efficient to use the low level API.
If your application is extreamly sensitive to latencies etc then you may
wanna use the low level API to have a very tightly coupled implementation
with your application where you can try to optimize it heavily for your use.
Another reason would be if you are running on a Realtime java JVM you can
use the low level API and build your functionality using Realtime constructs
such as RealTimeThreads, NoHeapRealTimeThreads and using the fancy memory
model for appropriately partitioning your object in importal and scope
memory. You can also write your own IO model using real time constructs as
it is pluggable in the current code.
>
> In terms of the typing, how would you like the API to look? We could
> possibly integrate any good ideas you have into our extended JMS API.
>
> > I am a single developer here who needs to quickly set up the broker and
> > start publishing/subscribing to data. All my development is new. I
> > need to deal with financial data, which means as low latency as
> > possible.
>
> I work for a tier one investment bank, in the front office - if you
> want, you can search for me on linkedin.com to see what I do. So high
> throughput and low latency are key requirements for me as well.
>
> It should be possible to get qpid running very quickly indeed -
> literally unzip the broker and it should work out of the box without
> any special configuration. People have been doing some work on our
> docs recently (it is something getting a lot of attention) so do let
> us know if anything is unclear or does not work as expected.
>
> Robert
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.13/1375 - Release Date: 4/12/2008
11:32 AM
Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.13/1375 - Release Date: 4/12/2008
11:32 AM
Re: General question regarding Java QPID
Posted by Rajith Attapattu <ra...@gmail.com>.
Rob,
Sorry this sliped my radar.
We don't have any dcoumentation. Your best bet is to look at the code.
https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid/java/common/src/main/java/org/apache/qpidity/transport/network/mina/
The dependencies on mina is isolated into the MinaHandler and MinaSender.
You can esily develop and alternative IO model by implement IoHandler and
Sender interfaces and then wiring them up in the Client.
Regards,
Rajith.
On Fri, May 9, 2008 at 2:18 PM, Robert Greig <ro...@gmail.com>
wrote:
> 2008/5/9 Rajith Attapattu <ra...@gmail.com>:
>
> > Rafi has made the IO model pluggable.
> > The AMQP layer in 0-10 code path doesn't have any dependencies on MINA
> byte
> > buffers etc.
> > So if one wants to write an alternate IO layer then there is a clear
> > mechanism to do that.
>
> I am quite interested in this. Is there any documentation or notes
> available?
>
> RG
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
Re: General question regarding Java QPID
Posted by Robert Greig <ro...@gmail.com>.
2008/5/9 Rajith Attapattu <ra...@gmail.com>:
> Rafi has made the IO model pluggable.
> The AMQP layer in 0-10 code path doesn't have any dependencies on MINA byte
> buffers etc.
> So if one wants to write an alternate IO layer then there is a clear
> mechanism to do that.
I am quite interested in this. Is there any documentation or notes available?
RG
Re: General question regarding Java QPID
Posted by Rajith Attapattu <ra...@gmail.com>.
On Fri, May 9, 2008 at 8:22 AM, Robert Greig <ro...@gmail.com>
wrote:
> 2008/5/9 Rajith Attapattu <ra...@gmail.com>:
>
> > Some of the reasons for using the AMQP API directly would be,
> > ===============================================
> > You want to dynamically create/delete exchanges/queues/bindings as part
> of
> > the application logic.
> > The JMS API works well if you pre create your exchange/queues/bindings
> using
> > the JNDI properties file.
>
> This is true just now but it does not imply that you need an "AMQP
> API" to do that since it does not conflict with a JMS API. You could
> easily add this capability to our "extended JMS API" and that is
> definitely what I would like to see if users want it.
I have no strong preference either way.
However I prefer Rafi's method of using Pure JMS as much as possible as
opposed to an extended JMS API.
>
> > If your application needs to query for different exchanges, bindings,
> queues
> > etc as part of your application logic then you would need to use the AMQP
> > API
>
> Again, since this doesn't conflict with JMS it could be added to our API.
>
> > If you want to have very fine grain flow controlling. The JMS impl deals
> > with only message units and use window mode (however we should make the
> byte
> > units configurable). If your application needs to switch between the
> > different flow control modes and/or change byte/message credits
> dynamically
> > as part of application logic then using the AMQP API makes sense.
>
> I think it would be interesting to see if we could add this into the
> JMS API. I need to understand the flow control in 0-10 a bit more
> before I could really comment however.
>
> > If your application is extreamly sensitive to latencies etc then you may
> > wanna use the low level API to have a very tightly coupled implementation
> > with your application where you can try to optimize it heavily for your
> use.
> > Another reason would be if you are running on a Realtime java JVM you can
> > use the low level API and build your functionality using Realtime
> constructs
> > such as RealTimeThreads, NoHeapRealTimeThreads and using the fancy memory
> > model for appropriately partitioning your object in importal and scope
> > memory. You can also write your own IO model using real time constructs
> as
> > it is pluggable in the current code.
>
> I think whatever the API that is provided, whether it is AMQP based or
> not, the above will be tricky particularly plugging in your own IO
> model unless that was designed into the API implementation.
Rafi has made the IO model pluggable.
The AMQP layer in 0-10 code path doesn't have any dependencies on MINA byte
buffers etc.
So if one wants to write an alternate IO layer then there is a clear
mechanism to do that.
>
>
> RG
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
Re: General question regarding Java QPID
Posted by Robert Greig <ro...@gmail.com>.
2008/5/9 Rajith Attapattu <ra...@gmail.com>:
>> I agree, I even think a lot of this could be done without requiring casting
>> to our own APIs, e.g. we could provide special topics/queues that permit
>> apps to access/manipulate broker wiring using ordinary JMS messages.
>>
>
> +1. This is my prefered way to do it as opposed to an extended JMS API where
> you have to cast down to specific classes.
I don't quite understand this. Perhaps I don't fully appreciate what
you are doing but surely using JMS like this is harder than using an
extended JMS API with few advantages? You end up having custom code
anyway that isn't portable since other JMS implementations (e.g Sonic)
will not understand the special messages you send, plus error handling
is much more complex - what do you do when the user gets something
wrong? Send a response message that they have to handle? Is that
really easier than throwing an exception that they can handle from a
regular method?
I don't see "pure JMS" as a goal in itself. If you need to expose
features or semantics that go beyond JMS you are non-portable. I hope
in time that when AMQP becomes ubiquitous that Sun will produce a
version of JMS with our extensions in it.
RG
Re: General question regarding Java QPID
Posted by Rajith Attapattu <ra...@gmail.com>.
On Fri, May 9, 2008 at 8:55 AM, Rafael Schloming <ra...@redhat.com> wrote:
> I would also caution that the low level API is most certainly less stable
> than JMS for two reasons: 1) AMQP itself has not reached 1.0 and is subject
> to certain changes until it does, and 2) our low level implementation is
> itself also subject to change. If you're willing to track these changes
> closely and likely become more involved in the qpid community then this may
> not be a problem, but if you just want to write your code and forget about
> it then JMS is probably the safer bet.
I second that. If you write against the current low level API then you have
to factor in the pain to do code changes if you want to move to a new AMQP
version. This is true for python, c++ as well. Things will be more stable
when we reach the 1.0 version.
>
> Robert Greig wrote:
>
>> 2008/5/9 Rajith Attapattu <ra...@gmail.com>:
>>
>> Some of the reasons for using the AMQP API directly would be,
>>> ===============================================
>>> You want to dynamically create/delete exchanges/queues/bindings as part
>>> of
>>> the application logic.
>>> The JMS API works well if you pre create your exchange/queues/bindings
>>> using
>>> the JNDI properties file.
>>>
>>
>> This is true just now but it does not imply that you need an "AMQP
>> API" to do that since it does not conflict with a JMS API. You could
>> easily add this capability to our "extended JMS API" and that is
>> definitely what I would like to see if users want it.
>>
>> If your application needs to query for different exchanges, bindings,
>>> queuesis etc as part of your application logic then you would need to use
>>> the AMQP
>>> API
>>>
>>
>> Again, since this doesn't conflict with JMS it could be added to our API.
>>
>
> I agree, I even think a lot of this could be done without requiring casting
> to our own APIs, e.g. we could provide special topics/queues that permit
> apps to access/manipulate broker wiring using ordinary JMS messages.
>
+1. This is my prefered way to do it as opposed to an extended JMS API where
you have to cast down to specific classes.
>
> If you want to have very fine grain flow controlling. The JMS impl deals
>>> with only message units and use window mode (however we should make the
>>> byte
>>> units configurable). If your application needs to switch between the
>>> different flow control modes and/or change byte/message credits
>>> dynamically
>>> as part of application logic then using the AMQP API makes sense.
>>>
>>
>> I think it would be interesting to see if we could add this into the
>> JMS API. I need to understand the flow control in 0-10 a bit more
>> before I could really comment however.
>>
>
> This only makes sense to use for messages that won't easily fit into
> memory, however I believe you could expose the functionality through
> BytesMessage.
+1 for exposing as much functionality as possible through pure JMS.
>
>
> --Rafael
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
Re: General question regarding Java QPID
Posted by Rafael Schloming <ra...@redhat.com>.
I would also caution that the low level API is most certainly less
stable than JMS for two reasons: 1) AMQP itself has not reached 1.0 and
is subject to certain changes until it does, and 2) our low level
implementation is itself also subject to change. If you're willing to
track these changes closely and likely become more involved in the qpid
community then this may not be a problem, but if you just want to write
your code and forget about it then JMS is probably the safer bet.
Robert Greig wrote:
> 2008/5/9 Rajith Attapattu <ra...@gmail.com>:
>
>> Some of the reasons for using the AMQP API directly would be,
>> ===============================================
>> You want to dynamically create/delete exchanges/queues/bindings as part of
>> the application logic.
>> The JMS API works well if you pre create your exchange/queues/bindings using
>> the JNDI properties file.
>
> This is true just now but it does not imply that you need an "AMQP
> API" to do that since it does not conflict with a JMS API. You could
> easily add this capability to our "extended JMS API" and that is
> definitely what I would like to see if users want it.
>
>> If your application needs to query for different exchanges, bindings, queuesis
>> etc as part of your application logic then you would need to use the AMQP
>> API
>
> Again, since this doesn't conflict with JMS it could be added to our API.
I agree, I even think a lot of this could be done without requiring
casting to our own APIs, e.g. we could provide special topics/queues
that permit apps to access/manipulate broker wiring using ordinary JMS
messages.
>> If you want to have very fine grain flow controlling. The JMS impl deals
>> with only message units and use window mode (however we should make the byte
>> units configurable). If your application needs to switch between the
>> different flow control modes and/or change byte/message credits dynamically
>> as part of application logic then using the AMQP API makes sense.
>
> I think it would be interesting to see if we could add this into the
> JMS API. I need to understand the flow control in 0-10 a bit more
> before I could really comment however.
This only makes sense to use for messages that won't easily fit into
memory, however I believe you could expose the functionality through
BytesMessage.
--Rafael
Re: General question regarding Java QPID
Posted by Robert Greig <ro...@gmail.com>.
2008/5/9 Rajith Attapattu <ra...@gmail.com>:
> Some of the reasons for using the AMQP API directly would be,
> ===============================================
> You want to dynamically create/delete exchanges/queues/bindings as part of
> the application logic.
> The JMS API works well if you pre create your exchange/queues/bindings using
> the JNDI properties file.
This is true just now but it does not imply that you need an "AMQP
API" to do that since it does not conflict with a JMS API. You could
easily add this capability to our "extended JMS API" and that is
definitely what I would like to see if users want it.
> If your application needs to query for different exchanges, bindings, queues
> etc as part of your application logic then you would need to use the AMQP
> API
Again, since this doesn't conflict with JMS it could be added to our API.
> If you want to have very fine grain flow controlling. The JMS impl deals
> with only message units and use window mode (however we should make the byte
> units configurable). If your application needs to switch between the
> different flow control modes and/or change byte/message credits dynamically
> as part of application logic then using the AMQP API makes sense.
I think it would be interesting to see if we could add this into the
JMS API. I need to understand the flow control in 0-10 a bit more
before I could really comment however.
> If your application is extreamly sensitive to latencies etc then you may
> wanna use the low level API to have a very tightly coupled implementation
> with your application where you can try to optimize it heavily for your use.
> Another reason would be if you are running on a Realtime java JVM you can
> use the low level API and build your functionality using Realtime constructs
> such as RealTimeThreads, NoHeapRealTimeThreads and using the fancy memory
> model for appropriately partitioning your object in importal and scope
> memory. You can also write your own IO model using real time constructs as
> it is pluggable in the current code.
I think whatever the API that is provided, whether it is AMQP based or
not, the above will be tricky particularly plugging in your own IO
model unless that was designed into the API implementation.
RG
Re: General question regarding Java QPID
Posted by Rajith Attapattu <ra...@gmail.com>.
On Thu, May 8, 2008 at 2:25 PM, Robert Greig <ro...@gmail.com>
wrote:
> 2008/5/8 Shahbaz Chaudhary <sc...@marcopolonetwork.com>:
> > I am interested in a non-jms api, frankly, for some silly reasons.
>
> Well, I don't think your reasons are silly. I have heard these things
> several times, so let me give you my perspective.
I second that, we have heard this from several folks.
>
>
> > have never gotten used to Java's (J2EE's actually) InitialContext, JNDI,
> > various configuration files, etc.
>
> The initial context is one bit that does tend to change from vendor to
> vendor so I agree it can be awkward. However I would argue that Qpid's
> implementation makes this as simple to use as possible - you basically
> need one properties file into which you can put the configuration. Or
> alternatively, of course, you do not need to use JNDI at all - you can
> construct AMQConnection objects.
>
> I would recommend the Qpid properties file configuration personally,
> since you inevitably want to put the configuration somewhere outside
> of your code.
>
> With Qpid you do not need any external JNDI server (unless you choose
> to use one of course).
As Rob mentioned the Qpid properties file is a nice way to get the JNDI
without having to mess up with external JNDI servers or any JEE nonsence.
Some of the recent additions I did makes it possible to configure
destinations with any exchange/routing key pair.
I am planning to add more documentation on this aspect.
>
> > I also expect that the AMQP library to be faster and possibly better
> > typed--so I don't deal with generic onMessage(Message) or
> > onMessage(Object), etc. functions ('generic' being used here as normal
> > English, not as Java's Generics)
>
> I don't think that an AMQP library would be faster in most cases. The
> way it is implemented, JMS does not add much overhead on the client.
> There are of course certain cases where it could be faster I grant you
> but I'd have to think a bit about that. Maybe others can jump in if
> they see any specific scenarios?
For most cases JMS should be fast and good enough.
The JMS consumer side will have one extra thread for dispatching which you
can avoid if you write your own stuff using the AMQP API.
But frankly the JMS implementation does take care of most of the grunt work
for you, so you could work at a fairly abstract level.
So unless you have a very compelling reason, it's good to use the JMS API.
Some of the reasons for using the AMQP API directly would be,
===============================================
You want to dynamically create/delete exchanges/queues/bindings as part of
the application logic.
The JMS API works well if you pre create your exchange/queues/bindings using
the JNDI properties file.
If your application needs to query for different exchanges, bindings, queues
etc as part of your application logic then you would need to use the AMQP
API
If you want to have very fine grain flow controlling. The JMS impl deals
with only message units and use window mode (however we should make the byte
units configurable). If your application needs to switch between the
different flow control modes and/or change byte/message credits dynamically
as part of application logic then using the AMQP API makes sense.
If you want fairly low level functionality. Ex If you want to write an
intermediary that only looks at certain message properties or delivery
properties or if you want to write some sort of intermediary that transforms
messages, then it would be a lot more efficient to use the low level API.
If your application is extreamly sensitive to latencies etc then you may
wanna use the low level API to have a very tightly coupled implementation
with your application where you can try to optimize it heavily for your use.
Another reason would be if you are running on a Realtime java JVM you can
use the low level API and build your functionality using Realtime constructs
such as RealTimeThreads, NoHeapRealTimeThreads and using the fancy memory
model for appropriately partitioning your object in importal and scope
memory. You can also write your own IO model using real time constructs as
it is pluggable in the current code.
>
> In terms of the typing, how would you like the API to look? We could
> possibly integrate any good ideas you have into our extended JMS API.
>
> > I am a single developer here who needs to quickly set up the broker and
> > start publishing/subscribing to data. All my development is new. I
> > need to deal with financial data, which means as low latency as
> > possible.
>
> I work for a tier one investment bank, in the front office - if you
> want, you can search for me on linkedin.com to see what I do. So high
> throughput and low latency are key requirements for me as well.
>
> It should be possible to get qpid running very quickly indeed -
> literally unzip the broker and it should work out of the box without
> any special configuration. People have been doing some work on our
> docs recently (it is something getting a lot of attention) so do let
> us know if anything is unclear or does not work as expected.
>
> Robert
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
Re: General question regarding Java QPID
Posted by Robert Greig <ro...@gmail.com>.
2008/5/8 Shahbaz Chaudhary <sc...@marcopolonetwork.com>:
> I am interested in a non-jms api, frankly, for some silly reasons.
Well, I don't think your reasons are silly. I have heard these things
several times, so let me give you my perspective.
> have never gotten used to Java's (J2EE's actually) InitialContext, JNDI,
> various configuration files, etc.
The initial context is one bit that does tend to change from vendor to
vendor so I agree it can be awkward. However I would argue that Qpid's
implementation makes this as simple to use as possible - you basically
need one properties file into which you can put the configuration. Or
alternatively, of course, you do not need to use JNDI at all - you can
construct AMQConnection objects.
I would recommend the Qpid properties file configuration personally,
since you inevitably want to put the configuration somewhere outside
of your code.
With Qpid you do not need any external JNDI server (unless you choose
to use one of course).
> I also expect that the AMQP library to be faster and possibly better
> typed--so I don't deal with generic onMessage(Message) or
> onMessage(Object), etc. functions ('generic' being used here as normal
> English, not as Java's Generics)
I don't think that an AMQP library would be faster in most cases. The
way it is implemented, JMS does not add much overhead on the client.
There are of course certain cases where it could be faster I grant you
but I'd have to think a bit about that. Maybe others can jump in if
they see any specific scenarios?
In terms of the typing, how would you like the API to look? We could
possibly integrate any good ideas you have into our extended JMS API.
> I am a single developer here who needs to quickly set up the broker and
> start publishing/subscribing to data. All my development is new. I
> need to deal with financial data, which means as low latency as
> possible.
I work for a tier one investment bank, in the front office - if you
want, you can search for me on linkedin.com to see what I do. So high
throughput and low latency are key requirements for me as well.
It should be possible to get qpid running very quickly indeed -
literally unzip the broker and it should work out of the box without
any special configuration. People have been doing some work on our
docs recently (it is something getting a lot of attention) so do let
us know if anything is unclear or does not work as expected.
Robert
RE: General question regarding Java QPID
Posted by Shahbaz Chaudhary <sc...@marcopolonetwork.com>.
I am interested in a non-jms api, frankly, for some silly reasons. I
have never gotten used to Java's (J2EE's actually) InitialContext, JNDI,
various configuration files, etc.
I also expect that the AMQP library to be faster and possibly better
typed--so I don't deal with generic onMessage(Message) or
onMessage(Object), etc. functions ('generic' being used here as normal
English, not as Java's Generics)
I am a single developer here who needs to quickly set up the broker and
start publishing/subscribing to data. All my development is new. I
need to deal with financial data, which means as low latency as
possible. My previous JMS experience is basically limited to what the
infrastructure folks set up for us.
Hope this helps.
Shahbaz
-----Original Message-----
From: Robert Greig [mailto:robert.j.greig@gmail.com]
Sent: Wednesday, May 07, 2008 10:40 AM
To: qpid-users@incubator.apache.org
Subject: Re: General question regarding Java QPID
2008/5/7 Shahbaz Chaudhary <sc...@marcopolonetwork.com>:
> Hi, I also started testing with the QPid version of the stack (rather
> than the Red hat mrg) because Qpid has a non-jms Java api.
On trunk (i.e. not yet a released version) there is a non-JMS low level
API.
> I was hoping to avoid JMS entirely, it sounds like the standard and
the
> expected practice is actually to use JMS for java based projects
rather
> than the AMQP specific api?
So far, we have found that almost all our users want a JMS API since
most people are either migrating from another JMS product or are
familiar with JMS due to its ubiquity. Things like Mule or Spring work
out of the box with Qpid for example because it is JMS compliant.
However, it may be that some people want to interact directly at the
protocol level and that was the motivation for having another API.
I would be very interested to know your reasons for wanting to avoid
JMS and also, if you can share it, what your use case is. This is so
that we can make sure we address all your requirements in the next
release(s). The people who have worked on the low level API can also
perhaps help out here.
Thanks,
Robert
Re: General question regarding Java QPID
Posted by Robert Greig <ro...@gmail.com>.
2008/5/7 Shahbaz Chaudhary <sc...@marcopolonetwork.com>:
> Hi, I also started testing with the QPid version of the stack (rather
> than the Red hat mrg) because Qpid has a non-jms Java api.
On trunk (i.e. not yet a released version) there is a non-JMS low level API.
> I was hoping to avoid JMS entirely, it sounds like the standard and the
> expected practice is actually to use JMS for java based projects rather
> than the AMQP specific api?
So far, we have found that almost all our users want a JMS API since
most people are either migrating from another JMS product or are
familiar with JMS due to its ubiquity. Things like Mule or Spring work
out of the box with Qpid for example because it is JMS compliant.
However, it may be that some people want to interact directly at the
protocol level and that was the motivation for having another API.
I would be very interested to know your reasons for wanting to avoid
JMS and also, if you can share it, what your use case is. This is so
that we can make sure we address all your requirements in the next
release(s). The people who have worked on the low level API can also
perhaps help out here.
Thanks,
Robert
RE: General question regarding Java QPID
Posted by Shahbaz Chaudhary <sc...@marcopolonetwork.com>.
Hi, I also started testing with the QPid version of the stack (rather
than the Red hat mrg) because Qpid has a non-jms Java api.
I was hoping to avoid JMS entirely, it sounds like the standard and the
expected practice is actually to use JMS for java based projects rather
than the AMQP specific api?
Thanks
Shahbaz
-----Original Message-----
From: Robert Greig [mailto:robert.j.greig@gmail.com]
Sent: Wednesday, May 07, 2008 10:18 AM
To: qpid-users@incubator.apache.org
Subject: Re: General question regarding Java QPID
2008/5/7 Kamran Saadatjoo <ka...@openflowsystems.com>:
> I'm very new to QPID, so please forgive me if my question is trivial.
Welcome to the list. Your question is not trivial at all; in fact it
is one that has provoked much discussion in the past!
> to know QPID because I was interested in the AMQP protocol. In going
through
> some of the examples (the Publisher.java and Subscriber.jave examples
in the
> Client pubsub directory in particular), I find that the AMQP methods
are not
> being used. Or maybe I don't understand how they are being used. Is
AMQP a
> subset of QPID? If so, why would I use the AMQP classes verses JMS?
Any
> light shed on this trivial question is greatly appreciated.
Hi Kamran,
In Java, JMS is the established standard API for messaging
applications. The Qpid Java client is fully JMS compliant and we
generally recommend to users to use it. Of course, like nearly every
messaging product, there are extensions and features that go beyond
the JMS specification and these are exposed over an "extended JMS API"
which extends the javax.jms.* interfaces where appropriate. We did
this because we did not want to force our users to make major changes
to existing JMS applications that they may have just to use certain
AMQP-specific features.
AMQP is the wire level protocol and other language implementations in
qpid (e.g. Python, Ruby etc) do track the protocol more closely.
However this does not mean that the other languages have greater
capabilities than the Java implementation just that the API tracks the
protocol.
A future release of Qpid may have a "low level" Java API that exposes
the protocol directly but that is really only intended for certain
specialised use cases.
Let us know if you have further questions.
Robert
RE: General question regarding Java QPID
Posted by Kamran Saadatjoo <ka...@openflowsystems.com>.
Thanks everyone for your quick responses and clarification. They helped a
lot.
Kamran Saadatjoo
-----Original Message-----
From: Robert Greig [mailto:robert.j.greig@gmail.com]
Sent: Wednesday, May 07, 2008 10:18 AM
To: qpid-users@incubator.apache.org
Subject: Re: General question regarding Java QPID
2008/5/7 Kamran Saadatjoo <ka...@openflowsystems.com>:
> I'm very new to QPID, so please forgive me if my question is trivial.
Welcome to the list. Your question is not trivial at all; in fact it
is one that has provoked much discussion in the past!
> to know QPID because I was interested in the AMQP protocol. In going
through
> some of the examples (the Publisher.java and Subscriber.jave examples in
the
> Client pubsub directory in particular), I find that the AMQP methods are
not
> being used. Or maybe I don't understand how they are being used. Is AMQP
a
> subset of QPID? If so, why would I use the AMQP classes verses JMS? Any
> light shed on this trivial question is greatly appreciated.
Hi Kamran,
In Java, JMS is the established standard API for messaging
applications. The Qpid Java client is fully JMS compliant and we
generally recommend to users to use it. Of course, like nearly every
messaging product, there are extensions and features that go beyond
the JMS specification and these are exposed over an "extended JMS API"
which extends the javax.jms.* interfaces where appropriate. We did
this because we did not want to force our users to make major changes
to existing JMS applications that they may have just to use certain
AMQP-specific features.
AMQP is the wire level protocol and other language implementations in
qpid (e.g. Python, Ruby etc) do track the protocol more closely.
However this does not mean that the other languages have greater
capabilities than the Java implementation just that the API tracks the
protocol.
A future release of Qpid may have a "low level" Java API that exposes
the protocol directly but that is really only intended for certain
specialised use cases.
Let us know if you have further questions.
Robert
Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.13/1375 - Release Date: 4/12/2008
11:32 AM
Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.13/1375 - Release Date: 4/12/2008
11:32 AM
Re: General question regarding Java QPID
Posted by Robert Greig <ro...@gmail.com>.
2008/5/7 Kamran Saadatjoo <ka...@openflowsystems.com>:
> I'm very new to QPID, so please forgive me if my question is trivial.
Welcome to the list. Your question is not trivial at all; in fact it
is one that has provoked much discussion in the past!
> to know QPID because I was interested in the AMQP protocol. In going through
> some of the examples (the Publisher.java and Subscriber.jave examples in the
> Client pubsub directory in particular), I find that the AMQP methods are not
> being used. Or maybe I don't understand how they are being used. Is AMQP a
> subset of QPID? If so, why would I use the AMQP classes verses JMS? Any
> light shed on this trivial question is greatly appreciated.
Hi Kamran,
In Java, JMS is the established standard API for messaging
applications. The Qpid Java client is fully JMS compliant and we
generally recommend to users to use it. Of course, like nearly every
messaging product, there are extensions and features that go beyond
the JMS specification and these are exposed over an "extended JMS API"
which extends the javax.jms.* interfaces where appropriate. We did
this because we did not want to force our users to make major changes
to existing JMS applications that they may have just to use certain
AMQP-specific features.
AMQP is the wire level protocol and other language implementations in
qpid (e.g. Python, Ruby etc) do track the protocol more closely.
However this does not mean that the other languages have greater
capabilities than the Java implementation just that the API tracks the
protocol.
A future release of Qpid may have a "low level" Java API that exposes
the protocol directly but that is really only intended for certain
specialised use cases.
Let us know if you have further questions.
Robert