semog wrote:
>
> I have checked in a fix for the timeout looping issue. I have more
> changes coming, but I felt that these changes were important enough to
> get checked in as soon as possible. Dealing with error handling code
> is difficult. If anyone having this particular problem would ca
I have checked in a fix for the timeout looping issue. I have more
changes coming, but I felt that these changes were important enough to
get checked in as soon as possible. Dealing with error handling code
is difficult. If anyone having this particular problem would care to
get the latest trunk
Well, they say that the sourcs code itself is the ultimate
documentation. :). But in this regard, there is not a single location
that lists all possible URI parameters for the .NET client in a single
location. I think the Java client is documented, and we try to stay
compatible, but I know there a
Jim Gomes wrote:
I am currently taking a look at this. Part of the solution is to set
a timeout for your transport using a URI parameter like so:
activemq:tcp://amqsrv:61616?transport.requesttimeout=1
Thanks Jim. BTW, is there any place (possibly in the source code) where
all possible U
I am currently taking a look at this. Part of the solution is to set
a timeout for your transport using a URI parameter like so:
activemq:tcp://amqsrv:61616?transport.requesttimeout=1
Where requesttimeout is in milliseconds. However, there is a bug with
the timeout, because it will continuo
