[
http://issues.apache.org/jira/browse/DIRMINA-196?page=comments#action_12372799
]
Kaspar Luethi commented on DIRMINA-196:
---------------------------------------
I had a similar problem (connection limiting) but solved it differently. I let
the user connect anyway, since i want so send him a higher level message
containing the reason for blocking his connection (have other reasons like IP
blocked, account banned etc.). All the messages go through a queue and I track
the average time to handle a message. so this gets me a simple dynamic
load-limiter:
//check logon policy: max backlog of 0.5s allowed
if((queue.size()+1)*averageMessageTime > 500) {
logger.info("Logon Policy, forbidden: <"+username+">");
error = -2147216217; //server kind of full
} else {
//logger.debug("Logon Policy, allowed");
}
Just an idea.
Wouldn't it be sufficient for your task, if you only react on sessionCreated()
and sessionClosed()?
How likely is it, that messageSent() detects that the max. sessions have been
reached? Zero, if you don't assign a new connection limit during runtime. But
if you add a new limit during runtime, it's pretty random, which users gets
thrown out. I would not want to just disconnect them, but either let them be
connected and let drop the connection count "naturally" by normal disconnects,
or i want to send this unlucky users at least a message like "we are full now,
sorry & bye".
> Connection shaper
> -----------------
>
> Key: DIRMINA-196
> URL: http://issues.apache.org/jira/browse/DIRMINA-196
> Project: Directory MINA
> Type: New Feature
> Versions: 0.9.2
> Reporter: Michael Bauroth
> Priority: Trivial
> Attachments: ConnectionShapeFilter.java
>
> How about to add an connection shaping filter (maybe to the examples)?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
