1.0.x didn't have that feature, so that's why it's not failing-- nothing
there to fail.
The idle timeout is in seconds and is a 32-bit value. It's multiplied
by 1000 to get milliseconds and passed into TimerSet(), so in order to
overrun that value, you'd need an idle timeout of more than 24 days. I
don't really understand your description of the problem below. Can you
Also, didn't you write this code to begin with?
On 9/24/12 5:45 PM, Craig Ruff wrote:
> I belive that, possibly due to a 2's compliment wrap around issue, enabling the
> max-idle-timeout is starting to fail due to the current seconds past the epoch
> value. Testing shows that the required value for max-idle-timeout is
> decreasing as time passes. For example, with max-idle-timeout set to 93900
> seconds, passing from the seconds past the epoch value of 1348525877 to
> 1348525896, the behavior went from starting successfully to failing immediately
> at startup. The log messages was:
> 24/09/2012 16:31:36 NOTICE: idle timeout set to 93900 seconds per system policy
> This would correspond to between:
> 1,348,619,677,000 and 1,348,619,696,000 milliseconds past the epoch.
> I don't have the time to track things down at the moment due to a
> the work commissioning a new data center, so I've had to disable
> the max-idle-timeout.
> This also is happenint in 1.1 beta, but not for a previous version of
> 1.0 something.