dev@genericjmsra.java.net

RE: Oracle AQ JMS connector

From: Laurent Sauvage <sauvagelaurent_at_hotmail.com>
Date: Wed, 14 Mar 2007 14:47:18 +0100

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
In summary, I can spare some time to develop/test oracle aq support in
generic ra, but not too much :)
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.
If I code directly from generic ra CVS sources, how do you plan to
evaluate/integrate my contribution ?

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
>
>