Hi Ramesh,
Sorry for misleading you. There is no provider specific way to handle
failures that occur on the Java end.
Oracle Streams AQ offers redelivery but that does not apply in case of a
runtime exception in our MDB.
On the event of Java exception the ojms client sets the state of the message
on the database queue table to 1 and does not process them again. Based on
the queue setup configuration in Oracle, all messages successfully processed
have their state set to 2 or they are removed from the queue.
What I meant by provider specific way was that I was able to differentiate
between processed and unprocessed messages, which is one of the reasons of
having DMD.
In our case almost 90% of the times the state is set to 1 when we have data
related issues. Once these issues are fixed, the status for those message
in the db are changed from 1 to 0 which makes then eligible to be
reprocessed.
Sounds crazy... but it works for now.
Hope this answers your question.
Ramesh Parthasarathy wrote:
>
> Hi Shailesh,
> Yes, you could use the same format from the blogs.
>
> Just curious, what is the provider specific option ?
> Thanks
> -Ramesh
>
> Shailesh Kini wrote:
>> Hello Ramesh,
>>
>> Yes, you are correct, I did not set the UserFirstXAForRedelivery option.
>> For
>> now I am using the Provider specific alternative. It also serves our
>> needs
>> well. If time permits I will give the redelivery a try. I will send the
>> link
>> to the instructions for setting up genericjmsra with OracleAQ soon.
>>
>> Is it OK if I just use the format from one of your blogs and just update
>> the
>> content for OracleAQ?
>>
>> Thanks!
>>
>> Best Regards,
>> Shailesh
>>
>> Ramesh Parthasarathy wrote:
>>
>>> Hi Shailesh,
>>> Redelivery is always tricky ! Since there is more than one XA (one
>>> for every delivery) involved, there is always the challenge of how we
>>> manage the XA resource state transitions at the broker side.Could you
>>> set gra log level to FINEST and send us the logs. Also i assume you
>>> have not set "UseFirstXAForRedelivery"
>>>
>>> Thanks
>>> -Ramesh
>>>
>>> Shailesh Kini wrote:
>>>
>>>> Hi Ramesh,
>>>>
>>>> I will document the steps after I am done with the some testing. So far
>>>> I
>>>> am
>>>> able to dequeue the message and process it in a XA transaction.
>>>> Everything
>>>> works if i set the redelivery count to 0.
>>>>
>>>> I have some issues configuring DMD. I have setup the reconnect
>>>> interval,
>>>> reconnect interval, enabled DMD to true and set the DMD CF and
>>>> Destination
>>>> in the activation spec. The connection factories and destinations are
>>>> successfully created.
>>>> After I set the redelivery count to 5 the GRA code loops and tries to
>>>> process the message 5 times if the MDB fails. After the redelivery
>>>> count
>>>> is
>>>> maxed out, GRA calls the SyncDeliveryHelper's sendMessageToDMD() to
>>>> push
>>>> the
>>>> message to DMD.
>>>>
>>>> Here's my question regarding DMD.
>>>> 1. The redeliverRequired return true and GRA calls
>>>> localXar.prepare(null);
>>>> passes a null to prepare. This causes the OracleXAResource to throw
>>>> OracleXAException. Is there any particular reason why a null is passed
>>>> to
>>>> this prepare call?
>>>>
>>>> Hope to hear from you soon.
>>>> Thanks and Best Regards,
>>>>
>>>> Shailesh
>>>>
>>>>
>>>> Thanks Shailesh,
>>>> Could you please make the steps available (through a blog/article),
>>>> we can publish it through the generic jms ra site.
>>>>
>>>> -Ramesh
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_genericjmsra.dev.java.net
>>> For additional commands, e-mail: users-help_at_genericjmsra.dev.java.net
>>>
>>>
>>>
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_genericjmsra.dev.java.net
> For additional commands, e-mail: users-help_at_genericjmsra.dev.java.net
>
>
>
--
View this message in context: http://www.nabble.com/GenericJMSRA-problems-configuration-for-AQ-conecction.-tp13120991p14403768.html
Sent from the Users of Generic Resource Adapter for JMS mailing list archive at Nabble.com.