Hi Laurent ,
please find responses below
-Ramesh
Laurent Sauvage wrote:
> Hi Ramesh,
>
> In fact, I tried to use it in production but it failed for no obvious reason
> (no stacktrace) whereas it works fine in preprod :-(
> I have no idea how to sync up fixes implemented in generic ra. That's a big
> issue, so I'm very interested in your synchronous path for the inbound even
> if I don't understand very well what it means :P
>
As of now generic RA depends on the ConnectionConsumer being implemented
by the JMS provider to receive messages from the JMS provider (inbound ,
to MDBs). This is an asynchronous way of receiving and processing
messages (chapter 8 of jms spec) and is very efficient and scalable, and
offers concurrent message delivery. But Chapter 8 (ConnectionConsumer)
is an optional part of the JMS spec and so some of the JMS providers
(Oracle AQ and WebLogic MQ) do not implement this. So, inbound
communication was not possible using generic ra and these JMS providers.
The other way to implement inbound communication would be to do a
sesssion.receive() which is the synchronous implementation, and
implementing concurrent message delivery (receiving and processing
messages in parallel threads) is not straightforward. This is what we
need in Generic RA now.
> In summary, I can spare some time to develop/test oracle aq support in
> generic ra, but not too much :)
>
Thanks for offering to contribute !
> At first, I am intending to reevaluate the neglected code I talked about in
> previous mail concerning
> oracle.jms.AQjmsConnectionFactory.getObjectInstance(), because it could lead
> to portable ConnectionFactory creation as it implements standard
> javax.naming.spi.ObjectFactory.
>
Your evaluation would be helpful.
> If I code directly from generic ra CVS sources, how do you plan to
> evaluate/integrate my contribution ?
>
We would be happy to review your contribution, and then before you can
integrate your changes, you would be required to sign the Sun
Contributor Agreement (license).
> Regards,
>
> Laurent.
>
> -----Message d'origine-----
> De : Ramesh.Parthasarathy_at_Sun.COM [mailto:Ramesh.Parthasarathy_at_Sun.COM]
> Envoyé : mardi 13 mars 2007 08:08
> À : Laurent Sauvage
> Cc : dev_at_genericjmsra.dev.java.net
> Objet : Re: Oracle AQ JMS connector
>
> Hi Laurent,
>
> Thanks for the details
>
> Few more queries
> Are you planning to use this as a temporary solution or permanently in a
> production system. If you are plannning for long term deployment , how do
> you plan to sync up fixes/features that are implemented in generic ra
> project into oraclemq.
>
> As i said in my earlier email, we are working on a synchronous path for the
> inbound and we would like the solution to have :
>
> 1. Concurrent message delivery.
> 2. XA transaction support.
> 3. Code being as portable as possible
> 4. Performant and scalable.
>
> Please let us know if you would be able to spare some time to develop/test
> the above.
>
> Or would you be willing to use generic ra if we implemented the above in a
> portable way (that works with Oracle AQ).
>
> Thanks
> -Ramesh
>
>
> Laurent Sauvage wrote On 03/12/07 15:41,:
>
>> Hi Ramesh,
>>
>> 1. The only safe way to create CFs for Oracle AQ is trough
>> AQjmsFactory AFAIK. A portable way to create CFs could be to define a
>> GenericFactoryClassName. In OracleAQ case it will be defined as
>> 'oracle.jms.AQjmsFactory'. But the problem of factory creation method
>> signatures remains.
>> NB: The method oracle.jms.AQjmsConnectionFactory.getObjectInstance()
>> can also build CFs by using JNDI attributes. I did not understand very
>> well this code then I left.
>> 2. No. I tested this connector with Oracle AQ 9i only (which does not
>> support distributed transactions but OracleAQ 10g does).
>> May be you're talking about normal transactions, I didn't test that
>>
> neither.
>
>> 3. Ok. I'll try to make a stress test later.
>> 4. I don't have much time to spend on this project however I guess I
>> could help.
>> The com.sun.genericra.inbound.AQjmsConnectionConsumer code could be
>> made generic quite easily.
>> Regarding the object builder portability, defining method signatures
>> through properties looks bad.
>> Any suggestion ?
>>
>> Regards,
>>
>> Laurent.
>>
>> -----Message d'origine-----
>> De : Ramesh.Parthasarathy_at_sun.com
>> [mailto:Ramesh.Parthasarathy_at_sun.com] De la part de Ramesh Envoyé :
>> lundi 12 mars 2007 14:51 À : sauvagelaurent_at_hotmail.com Cc :
>> dev_at_genericjmsra.dev.java.net Objet : Oracle AQ JMS connector
>>
>> Hi Laurent,
>>
>> Thanks for the pointer to the project, I had the following queries,
>> could you please share your thoughts :
>>
>> 1. The object builder for oracle, uses the AQJmsFactory APIs to
>> construct CFs. Is there a portable way to create these, just like its
>> done for other providers.
>> 2. Have you tried using transactions, it could be tough to implement
>> it in inbound but have you tested it for outbound ( the default seems
>> to be Notransaction).
>> 3. Did you get a chance to carry out a stress test on this setup, like
>> a 1000-5000 messages.
>> 4. We were planning on implementing the synchronous message path for
>> inbound to support providers like WebLogic MQ. Would you be
>> interested in making a contribution to this effort ? We would need a
>> much more portable code (connection consumer implementation) for the
>> inbound and also a portable way of building objects, Do you see any
>>
> problems here ?
>
>> Thanks
>> Ramesh
>>
>>
>>
>
>
>
>