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 clarify? 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. > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
