qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Ritchie" <ritch...@apache.org>
Subject Re: on how to use the qpid java client
Date Wed, 06 Jun 2007 08:44:13 GMT
On 06/06/07, Robert Greig <robert.j.greig@gmail.com> wrote:
> On 06/06/07, Rajith Attapattu <rajith77@gmail.com> wrote:
> > Hey Rob , knew this was comming :)
>
> Glad I did not let you down :-)
>
> > As for the flexible part considrer the following example. If I want to send
> > the same message to several destinations (different exchanges/routing key),
> > I can use the low level client to do  a "transfer by reference" where I send
> > the content once  followed by a several transfer methods to send the
> > different message headers. Very efficient if the message is large. ex. SOAP
> > attachment. ( message.open , several mesage.append methods to send the large
> > message , x nof message.transfers and message.close)
>
> I do not see why we would not want to expose this functionality via
> JMS. From the description it sounds to me very much like it would not
> be difficult to extend JMS to support this.
>
> Why would our business users not all want this for some specialised cases?
>
> > Here are some projects that are intested in this.
> > Apache Axis2 like a AMQP transport. They already have JMS transport and most
> > people use ActiveMQ :)
>
> It does mean they have to write the transport from scratch rather than
> just tweaking their JMS one.
>
> > A user on apache synapse said in one application he likes to do specific
> > things create/delete exchanges, queues etc only. If thats the case why would
> > he have to use JMS and only use the *non* standard" extensions we added.
> > He'd rather use the lowlevel client with minimum overhead and dependencies.
>
> The question is whether that fits into an overall strategy for all our
> users. As I see it we have different users with different
> requirements:
>
> 1) people who have an existing codebase written in terms of JMS
> (including e.g. Spring JMS higher leve stuff) and want to migrate to
> Qpid with as few changes as possible
>
> 2) people who are starting from no code but their corporate policy
> dictates that messaging should use JMS (I know at least one large
> corporation like that :-)) and the apps are simple so will just use
> standard JMS
>
> 3)  people who have a codebase written in terms of JMS but are
> interested in some of the capabilities that are being designed into
> AMQP
>
> 4) people who have no codebase and don't care about the API but want
> to exploit the features of AMQP
>
> Will the people in (4) walk away if they have to use a JMS-like API? I
> understand they will walk away if the API doesn't give them the
> flexibility or performance they require but from your post you imply
> that the mere fact it is a JMS API is a deal breaker.

I think that not allowing AMQP functionality via an extended JMS API
is a mistake. Going down this route would, IMHO, detriment AMQP. We
are trying to encourage people to use AMQP to that end we should be
looking to:

1) Make existing messaging application migration as easy as possible,
so in the java world that means JMS.

2) Make it easy to utilise the new AMQP functionality from existing
applications that are trying to utilise the new functionality of AMQP.
Again this should not require a wholesale change in messaging API.

Qpid Java is the only AMQP java client that I know of so I agree we
should have the ability to utilise the low level AMQP methods. However
if we do this without providing simultaneous JMS support then the
users might as well use the Qpid C client via JNI.

> > [RA]  I'd rather like to say that JMS support is a nice value addition than
> > the main goal of Qpid java.
>
> I find that a staggering statement. To help me understand can you
> please explain what you think the main goal of Qpid Java is?

I have to agree... the Qpid Java clients first goal should be JMS
support otherwise it is just another incompatible messaging product
requiring large scale re-engineering of existing code.

> > People understand the limitations of JMS. If u are driving a morris minor
> > and want the performance/experience of a ferrari u can try to change the
> > appearance or modify the engine. But to get the real experience of a ferrari
> > u need to get the actual one.
>
> You are phrasing this in terms of performance. Are you saying that a
> different API can provide better performance than one that implements
> JMS?
>
> > Yes cost/time will be an issue. Managers always play this card. There is
> > nothing free in this world.
>
> I think there is a serious underlying question here that we as a
> project have not yet written down: what are the goals for the project?
> What is our 6 month plan?

I agree here, we should be more open with the future plans for the project.

> You are right - nothing is free - and I think that we need to
> understand much more clearly the opportunity cost of another Java API.
>
> > [RA] People using a low level protocol API do so with the explicit
> > understanding that they may need to change code if they want to support a
> > newer version of the protocol. We don't need to kill ourselves to maintain
> > some pseudo API to insulate people from this kind of change. The low level
> > protocol is a 1-1 map of the AMQP classes and if they are
> > additions/deletions/modifications then it will be reflected in the new
> > version.
>
> But if that low level protocol API is the only way of getting access
> to certain features then we are effectively steering people to using
> that API.
>
> > All the messages they produce are of type AbstractJMSMessage which
> > implements javax.jms.Message.
>
> Is that such a big deal?
>
> > [RA] This is a good idea that I want to reuse. The ability to register
> > different factories for various mime types.
>
> It is kinda there just now but has not fully made it into the public API.
>
> > [RA] We need to build a product on a solid platform that can handle changes
> > to the protocol etc.
> > The current client did have some problems in that regard. We like to see
> > this situation addressed as soon as possible before our user base grows.
>
> I think there are a couple of discussions going on here: what should
> our API look like and what should we do with the current codebase for
> the client. You can argue for refactoring of the client codebase (as I
> would) without saying that we need to write a new API.
>
> > I understand that there are quite a few early adopters in JPMC, but I also
> > think they understand the risk of working with a protocol thats changing
> > rapidly.
>
> So we should have a page on the Qpid wiki saying "Note: please
> understand the risk of using this product due to the rapidly changing
> protocol" ?
>
> > [RA] Well indiscriminate use of system properties with no documentation is
> > not an acceptable alternative.

While I agree the lack of documentation is not acceptable (holding
hand up). I would hardly say there indiscriminate use of system
properties. The Client uses 12 System properties, half of which are
used to control dependencies such as Mina, JNDI or SASL.

Property (Default) Use
STRICT_AMQP (false) Interoperability with AMQP brokers that are
strictly AMQP compliant.

STRICT_AMQP_FATAL (false) Cause an exception if performing a JMS
function against an non capable strictly AMQP compliant broker.

IMMEDIATE_PREFETCH (false) Don't start prefetching until an explicit
receive or setMessageListener is called. Workaround for Mule.

org.apache.qpid.client.verifyQueueBindingBeforePublish (true) Required
for JMS compliance. Another example of an extension to AMQP 0_8 to
provide JMS compliance.

amq.dynamicsaslregistrar.properties ()  Used to specify a non standard
SASL properties file

amqj.protocolprovider.class () Used to specify an alternative Broker
for the InVM broker.

java.naming.provider.url () Part of JNDI

Properties that can be used to adjust the Mina connection.
amqj.heartbeat.timeoutFactor
amqj.tcpNoDelay
amqj.heartbeat.delay
amqj.sendBufferSize
amqj.receiveBufferSize

When you look at the list STRICT_AMQP, IMMEDIATE_PREFETCH and
verifyQueueBindingBeforePublish are the only ones that directly affect
the client functionality.

For 99.9% of users they need not know of the existence of these
properties. True they should be (and I shall put them up) on the wiki.
However there are real needs to have them as the current Qpid Java
client is JMS focused so the priorities are passing the TCK, working
well with existing JMS tools and interoperability with other AMQP
brokers.

> You make tradeoffs based on the resources available and the
> priorities. Nobody is arguing that system properties with no
> documentation is the way to go but given the limited set of things
> that anyone would want to change (mostly these were added for testing
> out performance tweaks) it was acceptable at the time. Opportunity
> cost again.
>
> > [RA] Well this is not the proper way to do it. We are working on adding the
> > nessacery support for JMS features like queue browsing etc to the protocol.
> > So as a temporary messure it's ok.
>
> I am glad you approve.
>
> > [RA] I think this will confuse end users.
> > We have the javax.jms.Session.createQueue(String name) and if people want to
> > use AMQP stuff there is the
> > createQueue(String queueName, boolean autoDelete ....). But to use that now
> > u need to cast the jms sesson in to AMQSession.
>
> You don't need to cast to AMQSession anywhere - that is an implementation class.
>
> > I would rather people use JMS properly and if they need AMQP features they
> > can use a proper API for that. YMMV
>
> So you are saying to people with an existing codebase that they need
> to rewrite if they want any real value from using our project.
>
> RG
>




-- 
Martin Ritchie

Mime
View raw message