One more thing : the SQL Exception shouldn't be hidden, it should be logged
within the TransportConnection.serviceTransportException function or
somewhere else.
Adrian Tarau wrote:
>
> Hello James,
>
> Finally, I've located the problem - transport failure & locking.
> I switched to an Oracle database, just to avoid additional problems
> related with journaling & derby - so this change was causing the problem.
>
> I have an Oracle 9.X database and I've used JDBC driver ojdbc-9.0.2. When
> the object was above 130K an SQL exception : "ORA-17070: Data size bigger
> than max size for this type" was threw out and
> TransportConnection.serviceTransportException was called, which disposed
> the transport(VM Transport).
>
> After that the consumers&producers failed because a producer failed with
> an SQLException(question : Why the whole connection/transport should
> fail???).
>
> At least I had the chance to test the failover transport :) , so I used
> that. There is not exception now, only the large messages failed, but the
> consumers are locked now in close(see another post, in the same thread)
>
> It seems to a problem with cleaning the locks, during an SQLException(or
> any exception).
>
> As soon as I switched to the latest JDBC driver(10.2.0.1.0, maybe is not
> the latest but a driver from Oracle 10g) everything worked fine - so no
> more SQLExceptions because of the stupid Oracle 8&9 BLOB issues.
>
>
> James.Strachan wrote:
>>
>> On 5/21/07, Adrian Tarau <[EMAIL PROTECTED]> wrote:
>>>
>>> Hello,
>>>
>>> I have the following problem : A connection(embedded broker, vm
>>> transport)
>>> is created and then a few sessions. I poll for messages, with my own
>>> threads
>>> in order to do throttling. One thing that confuses me is : if an
>>> exception
>>> occurs somewhere in the transport(for example an interrupt on the
>>> consuming
>>> thread) , the connection is closed with all the sessions and
>>> consumers/producers.
>>
>> AFAIK thread interupt exceptions won't close a
>> connection/session/transport. You sure its not some other underlying
>> excpetion?
>>
>>
>>> I was able to listen for such an exceptions(with
>>> Connection.setExceptionListener(...)) and recreate the connection. I
>>> tried
>>> also with connectionFactory.setBrokerURL("failover:vm://localhost")
>>> which
>>> supposed to fix problems like this one, and to reconnect, but is not
>>> working
>>> as espected.
>>
>> When using vm:// you should never really need failover, since the
>> broker is in the same JVM. Failover is intended for use with TCP where
>> a remote broker may fail.
>>
>> Even if you were having a transport level exception (which shouldn't
>> really happen with vm:// but maybe there's a bug & we should catch &
>> handle InteruptedException better) then failover does the re-creation
>> of all the connection/sessions for you so there's no real point trying
>> to replicate that yourself (as you'll be opening all kinds of cans of
>> worms, like figuring out which messages, transactions &
>> acknowledgements were in progress & re-submitting them - all of which
>> failover: already handles.
>>
>> BTW 4.0.2 is quite old, I'd recommend upgrading to 4.1.1
>> --
>> James
>> -------
>> http://macstrac.blogspot.com/
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/Transport-Exceptions-close-the-connection-tf3791363s2354.html#a10880354
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
