Simon what are your timelines? The new 0-10 client will be ready soon. The 0-10 version of the protocol has significan't improvements over 0-8. So I recomened waiting for the new client code.
As Rupert says if u use JMS there wan't be any problems. But if you want to use AMQP specific features I suggets you wait till we do the new client. The code shown below will not be supported from 0-10 onwards. Regards, Rajith On 7/27/07, Rupert Smith <[EMAIL PROTECTED]> wrote: > > If does it won't impact your message throughput. At the moment Java broker > performance is switching from io bound to cpu bound on a fairly large > message size (*ahem* thats a round about way of waying that performance is > not so hot that you will notice any difference). You won't get anywhere > near > to saturating your network on tiny messages. This may become more of an > issue as the broker throughput is improved. At the moment the direct AMQP > API and the JMS API have identical throughput, and it is an ongoing aim of > the project to ensure that the JMS API remains as performant as any lower > level API. > > I would recomend sticking with JMS, because the AMQP API is in flux and > the > code that currently exists is not really intended for exposure as a public > API; it is an odd mix of JMS with some AMQP stuff thrown in. If you want > to > try it out, there's no reason we should try and stop you. So here is a > very > approximate outline of setting up a message consumer, on a direct > exchange: > > Connection connection = new AMQConnection(brokerDetails, username, > password, > clientID, virtualpath); > Session session = (AMQSession)connection.createSession(transacted, > ackMode); > > AMQShortString destinationName = new AMQShortString(desintationName); > > Destination destination = new AMQQueue( > ExchangeDefaults.DIRECT_EXCHANGE_NAME, > destinationName, destinationName, false, false, isDurable); > > session.createQueue(destinationName, false, isDurable, false); > session.bindQueue(destinationName, destinationName, null, > ExchangeDefaults.DIRECT_EXCHANGE_NAME); > > MessageConsumer consumer = session.createConsumer(destination, > PREFETCH_DEFAULT, NO_LOCAL_DEFAULT, EXCLUSIVE_DEFAULT, selector); > > consumer.setMessageListener(this); > > I just cut and pasted a few lines from the PingPongProducer class to > provide > the above. There may be some better examples around. > > Rupert > > On 27/07/07, Simon Jones <[EMAIL PROTECTED]> wrote: > > > > I'm planning a system that will process large volumes of very small > > messages. Some of the producers and consumers will be 3rd party non-JMS > > based using an internal protocol for the payload. My concern with JMS is > > that it might add data (headers/payload etc) to support JMS semantics > > that some non-JMS AMQP systems will not know how to handle. > > Additionally, this data could be significant compared to the payload. > > Does the JMS API add any overhead to the message size compared to using > > AMQP directly? > > > > Thanks, > > Simon > > > > Robert Greig wrote: > > > On 27/07/07, Simon Jones <[EMAIL PROTECTED]> wrote: > > > > > > > > >> I want to use the Java client but don't want to use the JMS API. > What's > > >> the recommended Java API that gives me direct access to the AMQP > > >> exchange, queues and messages? Are there any examples showing how to > do > > >> this? > > >> > > > > > > We don't have an official AMQP-level API at the moment although in the > > > next version we will be building the JMS API on top of an AMQP-level > > > API. > > > > > > What is it that the JMS API does not provide for you in the current > > > version? We may be able to offer alternative approaches. > > > > > > RG > > > > > > > > > > -- > > Simon Jones > > IT Consultant > > > > Tel: +44 1926 886467 > > Fax: +44 8703 305708 > > Mob: +44 7771 561530 > > > > Black Pepper Software Limited > > The Mews, Trinity House, Trinity Street, Leamington Spa, Warwickshire. > > CV32 5YN > > > > Registered in England, No. 3763392 > > VAT No. 747 8497 68 > > > > >
