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#a10878218
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
