activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Allan Schrum (JIRA)" <>
Subject [jira] Commented: (AMQNET-122) Recent OpenWireFormat changes cause initial startup delays
Date Fri, 07 Nov 2008 19:09:05 GMT


Allan Schrum commented on AMQNET-122:

In Apache.NMS the file NMSConstants.cs has a new variable called defaultRequestTimeout = TimeSpan.FromMilliseconds(Timeout.Infinite).
This is used in conjunction with another thread to handle timeout. It is thought that the
above value would cause one thread to block forever (until the blocking signal occurs). When
working on failover addition to Apache.NMS.ActiveMQ it was noticed that when Timeout.Infinite
was used it didn't block. Rather it returned immediately and continued on. Using the "traditional"
default timeout of 1 ms caused the threads to context switch which allowed the mutex to properly
fire and all was well.

I do not know if this is the cause of the problem, but it is focused on the use of RequestTimeout
of TcpTransport.cs which is initialized to this constant.

> Recent OpenWireFormat changes cause initial startup delays
> ----------------------------------------------------------
>                 Key: AMQNET-122
>                 URL:
>             Project: ActiveMQ .Net
>          Issue Type: Bug
>          Components: ActiveMQ Client
>         Environment: Windows XP, ActiveMQ 5.2.0 RC2+, latest Apache.NMS and Apache.NMS.ActiveMQ
>            Reporter: Allan Schrum
>            Assignee: Jim Gomes
> The recent changes to Apache.NMS.ActiveMQ's file OpenWire/OpenWireFormat.cs create massive
delays on my system. If I revert that file back to the version 693666 (09-Sep-2008) then all
my code starts working without delays. It seems that the action of writing to the bus (using
Topics in my case) is delayed 120 seconds or so. Each write seems to be delayed 15 seconds.
Since startup involves several writes the initialize the wire format, I suspect that a timeout
variable is set to 0 (zero) which does not allow a thread-swap to take place. I suspect that
the timeout should be set to 1 ms so that a context switch will take place.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message