Am 27.05.2009 um 22:42 schrieb Niklas Gustavsson:
On Wed, May 27, 2009 at 2:17 PM, Sai Pullabhotla
<[email protected]> wrote:
Not sure why you think it will break the API, as I could not find
anywhere
the "idleTimeout" being documented as maximum idle time. Below is the
Javadoc from the ListenerFactory:
* Set the number of seconds during which no network activity
* is allowed before a session is closed due to inactivity.
*
* @param idleTimeout The idle timeout in seconds
So, to keep things simple, we should just mark it as a bug and make
it the
default timeout. Also, pre 1.0 releases worked fine with listener
timeout
set to a finite value and user timeout left at zero. so, I guess
the issue
is with 1.0/1.0.1.
I think the problem is that we don't agree on what the bug is :-)
The idle time on the listeners has always been the maximum enforced
idle time for that listener (note that you can enforce different idle
time for different listeners, for example allow those connecting over
the intranet to idle longer). And I even think our documentation makes
this clear: http://mina.apache.org/ftpserver/listeners.html states
that the idle-time is "The number of seconds before an inactive client
is disconnected ", not the default value for the user level setting. I
do think our documentation should be more descriptive though. I also
think that it's a bug that we treat an unlimited user value
incorrectly (overriding the listener finite value).
I would strongly oppose changing how this configuration work.
If a default value is needed, we can add a new configuration for it.
However, I'm personally still not convinced by the example put
forward. if someone has 500 users I would assume the probably store
these in a database, in which case it's one SQL statement to change
that value for all users. Besides, it's not like we offer defaults for
the other user level configurations, given this example, one would be
as likely to need default values for concurrent logins and transfer
limits as well.
/niklas
So if you fix what you have identified as the bug, I think everybody
would be happy, because setting the *maximum* idle timeout on listener
level would then force the infinite user level timeout to this maximum
value. So in fact it would work like a default for the user level
timeout, which is exactly what we want.
Johannes
