You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Niklas Therning (JIRA)" <ji...@apache.org> on 2006/03/05 11:02:40 UTC
[jira] Created: (DIRMINA-185) Refactor IoFilter life cycle
management
Refactor IoFilter life cycle management
---------------------------------------
Key: DIRMINA-185
URL: http://issues.apache.org/jira/browse/DIRMINA-185
Project: Directory MINA
Type: Improvement
Reporter: Niklas Therning
Priority: Minor
I thought it would be good to have this discussion in JIRA. Please add your thoughs to this issue. Below I'll try to give a background to the problem.
Recently, a discussion on IoFilter life cycle management has been going on on the MINA mailing list. Questions have been raised whether MINA should provide life cycle management (LCM) for all filters (the current situation), if it should be optional (either on by default or off by default) or if it shouldn't be supported at all.
In version 0.9.2 of MINA IoFilter has six LCM methods:
init, onPreAdd, onPostAdd, onPreRemove, onPostRemove and destroy
The LCM is handled by AbstractIoFilterChain and the singleton IoFilterLifeCycleManager. IoFilterLifeCycleManager uses reference counting to determine whether init/destroy should be called when a filter is added to/removed from a filter chain.
In MINA 0.8 filter chains were typically shared among sessions. This meant that init/destroy would only be called once (or at least very few times) in the lifetime of an application. However, in MINA 0.9 filter chains are always per session which means that in some circumstances init/destroy will be called very frequently.
The discussion on LCM forked from the discussion on DIRMINA-169. The LCM described above causes a deadlock in the current implementation of ThreadPoolFilter.
How do you think MINA should handle LCM?
--
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
Re: [jira] Commented: (DIRMINA-185) Refactor IoFilter life cycle management
Posted by Maarten Bosteels <ma...@dns.be>.
>
> Trustin Lee commented on DIRMINA-185:
> -------------------------------------
>
> Will we have another type like an IoFilter, which has a life cycle? I'm not sure about this, so introducing too generic interface might not be a good move. Any prospection?
WorkerThreads ?
[jira] Commented: (DIRMINA-185) Refactor IoFilter life cycle
management
Posted by "Trustin Lee (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-185?page=comments#action_12369020 ]
Trustin Lee commented on DIRMINA-185:
-------------------------------------
Will we have another type like an IoFilter, which has a life cycle? I'm not sure about this, so introducing too generic interface might not be a good move. Any prospection?
> Refactor IoFilter life cycle management
> ---------------------------------------
>
> Key: DIRMINA-185
> URL: http://issues.apache.org/jira/browse/DIRMINA-185
> Project: Directory MINA
> Type: Improvement
> Reporter: Niklas Therning
> Priority: Minor
>
> I thought it would be good to have this discussion in JIRA. Please add your thoughs to this issue. Below I'll try to give a background to the problem.
> Recently, a discussion on IoFilter life cycle management has been going on on the MINA mailing list. Questions have been raised whether MINA should provide life cycle management (LCM) for all filters (the current situation), if it should be optional (either on by default or off by default) or if it shouldn't be supported at all.
> In version 0.9.2 of MINA IoFilter has six LCM methods:
> init, onPreAdd, onPostAdd, onPreRemove, onPostRemove and destroy
> The LCM is handled by AbstractIoFilterChain and the singleton IoFilterLifeCycleManager. IoFilterLifeCycleManager uses reference counting to determine whether init/destroy should be called when a filter is added to/removed from a filter chain.
> In MINA 0.8 filter chains were typically shared among sessions. This meant that init/destroy would only be called once (or at least very few times) in the lifetime of an application. However, in MINA 0.9 filter chains are always per session which means that in some circumstances init/destroy will be called very frequently.
> The discussion on LCM forked from the discussion on DIRMINA-169. The LCM described above causes a deadlock in the current implementation of ThreadPoolFilter.
> How do you think MINA should handle LCM?
--
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
[jira] Commented: (DIRMINA-185) Refactor IoFilter life cycle
management
Posted by "peter royal (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-185?page=comments#action_12377006 ]
peter royal commented on DIRMINA-185:
-------------------------------------
I just committed a patch that removes the LCM, and adds a wrapper class that contains the reference counting behavior.
> Refactor IoFilter life cycle management
> ---------------------------------------
>
> Key: DIRMINA-185
> URL: http://issues.apache.org/jira/browse/DIRMINA-185
> Project: Directory MINA
> Type: Improvement
> Reporter: Niklas Therning
> Priority: Minor
>
> I thought it would be good to have this discussion in JIRA. Please add your thoughs to this issue. Below I'll try to give a background to the problem.
> Recently, a discussion on IoFilter life cycle management has been going on on the MINA mailing list. Questions have been raised whether MINA should provide life cycle management (LCM) for all filters (the current situation), if it should be optional (either on by default or off by default) or if it shouldn't be supported at all.
> In version 0.9.2 of MINA IoFilter has six LCM methods:
> init, onPreAdd, onPostAdd, onPreRemove, onPostRemove and destroy
> The LCM is handled by AbstractIoFilterChain and the singleton IoFilterLifeCycleManager. IoFilterLifeCycleManager uses reference counting to determine whether init/destroy should be called when a filter is added to/removed from a filter chain.
> In MINA 0.8 filter chains were typically shared among sessions. This meant that init/destroy would only be called once (or at least very few times) in the lifetime of an application. However, in MINA 0.9 filter chains are always per session which means that in some circumstances init/destroy will be called very frequently.
> The discussion on LCM forked from the discussion on DIRMINA-169. The LCM described above causes a deadlock in the current implementation of ThreadPoolFilter.
> How do you think MINA should handle LCM?
--
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
[jira] Commented: (DIRMINA-185) Refactor IoFilter life cycle
management
Posted by "Trustin Lee (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-185?page=comments#action_12368973 ]
Trustin Lee commented on DIRMINA-185:
-------------------------------------
I agree with Peter. So, here's my idea:
* Remove IoFilter.init() and IoFilter.destroy();
* Create a new utility decorator class. say, 'IoFilterWithLifeCycle' (Please suggest better names), which
* provides a protected void init() and destroy().
* implements other lifecycle methods in IoFilter so it calls init() and destroy() properly.
WDYT?
> Refactor IoFilter life cycle management
> ---------------------------------------
>
> Key: DIRMINA-185
> URL: http://issues.apache.org/jira/browse/DIRMINA-185
> Project: Directory MINA
> Type: Improvement
> Reporter: Niklas Therning
> Priority: Minor
>
> I thought it would be good to have this discussion in JIRA. Please add your thoughs to this issue. Below I'll try to give a background to the problem.
> Recently, a discussion on IoFilter life cycle management has been going on on the MINA mailing list. Questions have been raised whether MINA should provide life cycle management (LCM) for all filters (the current situation), if it should be optional (either on by default or off by default) or if it shouldn't be supported at all.
> In version 0.9.2 of MINA IoFilter has six LCM methods:
> init, onPreAdd, onPostAdd, onPreRemove, onPostRemove and destroy
> The LCM is handled by AbstractIoFilterChain and the singleton IoFilterLifeCycleManager. IoFilterLifeCycleManager uses reference counting to determine whether init/destroy should be called when a filter is added to/removed from a filter chain.
> In MINA 0.8 filter chains were typically shared among sessions. This meant that init/destroy would only be called once (or at least very few times) in the lifetime of an application. However, in MINA 0.9 filter chains are always per session which means that in some circumstances init/destroy will be called very frequently.
> The discussion on LCM forked from the discussion on DIRMINA-169. The LCM described above causes a deadlock in the current implementation of ThreadPoolFilter.
> How do you think MINA should handle LCM?
--
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
[jira] Resolved: (DIRMINA-185) Refactor IoFilter life cycle
management
Posted by "peter royal (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-185?page=all ]
peter royal resolved DIRMINA-185:
---------------------------------
Fix Version: 0.9.4
Resolution: Fixed
LCM has been refactored.
> Refactor IoFilter life cycle management
> ---------------------------------------
>
> Key: DIRMINA-185
> URL: http://issues.apache.org/jira/browse/DIRMINA-185
> Project: Directory MINA
> Type: Improvement
> Reporter: Niklas Therning
> Priority: Minor
> Fix For: 0.9.4
>
> I thought it would be good to have this discussion in JIRA. Please add your thoughs to this issue. Below I'll try to give a background to the problem.
> Recently, a discussion on IoFilter life cycle management has been going on on the MINA mailing list. Questions have been raised whether MINA should provide life cycle management (LCM) for all filters (the current situation), if it should be optional (either on by default or off by default) or if it shouldn't be supported at all.
> In version 0.9.2 of MINA IoFilter has six LCM methods:
> init, onPreAdd, onPostAdd, onPreRemove, onPostRemove and destroy
> The LCM is handled by AbstractIoFilterChain and the singleton IoFilterLifeCycleManager. IoFilterLifeCycleManager uses reference counting to determine whether init/destroy should be called when a filter is added to/removed from a filter chain.
> In MINA 0.8 filter chains were typically shared among sessions. This meant that init/destroy would only be called once (or at least very few times) in the lifetime of an application. However, in MINA 0.9 filter chains are always per session which means that in some circumstances init/destroy will be called very frequently.
> The discussion on LCM forked from the discussion on DIRMINA-169. The LCM described above causes a deadlock in the current implementation of ThreadPoolFilter.
> How do you think MINA should handle LCM?
--
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
[jira] Commented: (DIRMINA-185) Refactor IoFilter life cycle
management
Posted by "Trustin Lee (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-185?page=comments#action_12377673 ]
Trustin Lee commented on DIRMINA-185:
-------------------------------------
Peter's change looks great. Niklas, could you close this issue after your review?
> Refactor IoFilter life cycle management
> ---------------------------------------
>
> Key: DIRMINA-185
> URL: http://issues.apache.org/jira/browse/DIRMINA-185
> Project: Directory MINA
> Type: Improvement
> Reporter: Niklas Therning
> Priority: Minor
> Fix For: 0.9.4
>
> I thought it would be good to have this discussion in JIRA. Please add your thoughs to this issue. Below I'll try to give a background to the problem.
> Recently, a discussion on IoFilter life cycle management has been going on on the MINA mailing list. Questions have been raised whether MINA should provide life cycle management (LCM) for all filters (the current situation), if it should be optional (either on by default or off by default) or if it shouldn't be supported at all.
> In version 0.9.2 of MINA IoFilter has six LCM methods:
> init, onPreAdd, onPostAdd, onPreRemove, onPostRemove and destroy
> The LCM is handled by AbstractIoFilterChain and the singleton IoFilterLifeCycleManager. IoFilterLifeCycleManager uses reference counting to determine whether init/destroy should be called when a filter is added to/removed from a filter chain.
> In MINA 0.8 filter chains were typically shared among sessions. This meant that init/destroy would only be called once (or at least very few times) in the lifetime of an application. However, in MINA 0.9 filter chains are always per session which means that in some circumstances init/destroy will be called very frequently.
> The discussion on LCM forked from the discussion on DIRMINA-169. The LCM described above causes a deadlock in the current implementation of ThreadPoolFilter.
> How do you think MINA should handle LCM?
--
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
[jira] Closed: (DIRMINA-185) Refactor IoFilter life cycle
management
Posted by "Niklas Therning (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-185?page=all ]
Niklas Therning closed DIRMINA-185:
-----------------------------------
Thanks Pete!
> Refactor IoFilter life cycle management
> ---------------------------------------
>
> Key: DIRMINA-185
> URL: http://issues.apache.org/jira/browse/DIRMINA-185
> Project: Directory MINA
> Type: Improvement
> Reporter: Niklas Therning
> Priority: Minor
> Fix For: 0.9.4
>
> I thought it would be good to have this discussion in JIRA. Please add your thoughs to this issue. Below I'll try to give a background to the problem.
> Recently, a discussion on IoFilter life cycle management has been going on on the MINA mailing list. Questions have been raised whether MINA should provide life cycle management (LCM) for all filters (the current situation), if it should be optional (either on by default or off by default) or if it shouldn't be supported at all.
> In version 0.9.2 of MINA IoFilter has six LCM methods:
> init, onPreAdd, onPostAdd, onPreRemove, onPostRemove and destroy
> The LCM is handled by AbstractIoFilterChain and the singleton IoFilterLifeCycleManager. IoFilterLifeCycleManager uses reference counting to determine whether init/destroy should be called when a filter is added to/removed from a filter chain.
> In MINA 0.8 filter chains were typically shared among sessions. This meant that init/destroy would only be called once (or at least very few times) in the lifetime of an application. However, in MINA 0.9 filter chains are always per session which means that in some circumstances init/destroy will be called very frequently.
> The discussion on LCM forked from the discussion on DIRMINA-169. The LCM described above causes a deadlock in the current implementation of ThreadPoolFilter.
> How do you think MINA should handle LCM?
--
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
[jira] Commented: (DIRMINA-185) Refactor IoFilter life cycle
management
Posted by "Trustin Lee (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-185?page=comments#action_12368975 ]
Trustin Lee commented on DIRMINA-185:
-------------------------------------
This issue relates to DIRMINA-169 very closely.
If we remove IoFilter.init() and destroy(), then how can users wrap ThreadPoolFilter with IoFilterWithLifeCycle class? We cannot if we don't have any standardized names. We need to add another interface which provides standard method names so users can wrap ThreadPoolFilter and IoFilterWithLifeCycle call ThreadPoolFilter.init() and destroy() appropriately. For example:
interface LifeCycleSupport { // or we could extend IoFilter
void start() throws Exception;
void stop() throws Exception;
}
public class ThreadPoolFilter implements IoFilter, LifeCycleSupport {
...
}
public class IoFilterWithLifeCycle {
public void start()
{
...
if( wrappedFilter instanceof LifeCycleSupport ) {
wrappedFilter.start();
}
...
}
}
> Refactor IoFilter life cycle management
> ---------------------------------------
>
> Key: DIRMINA-185
> URL: http://issues.apache.org/jira/browse/DIRMINA-185
> Project: Directory MINA
> Type: Improvement
> Reporter: Niklas Therning
> Priority: Minor
>
> I thought it would be good to have this discussion in JIRA. Please add your thoughs to this issue. Below I'll try to give a background to the problem.
> Recently, a discussion on IoFilter life cycle management has been going on on the MINA mailing list. Questions have been raised whether MINA should provide life cycle management (LCM) for all filters (the current situation), if it should be optional (either on by default or off by default) or if it shouldn't be supported at all.
> In version 0.9.2 of MINA IoFilter has six LCM methods:
> init, onPreAdd, onPostAdd, onPreRemove, onPostRemove and destroy
> The LCM is handled by AbstractIoFilterChain and the singleton IoFilterLifeCycleManager. IoFilterLifeCycleManager uses reference counting to determine whether init/destroy should be called when a filter is added to/removed from a filter chain.
> In MINA 0.8 filter chains were typically shared among sessions. This meant that init/destroy would only be called once (or at least very few times) in the lifetime of an application. However, in MINA 0.9 filter chains are always per session which means that in some circumstances init/destroy will be called very frequently.
> The discussion on LCM forked from the discussion on DIRMINA-169. The LCM described above causes a deadlock in the current implementation of ThreadPoolFilter.
> How do you think MINA should handle LCM?
--
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
[jira] Commented: (DIRMINA-185) Refactor IoFilter life cycle
management
Posted by "Niklas Therning (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-185?page=comments#action_12377747 ]
Niklas Therning commented on DIRMINA-185:
-----------------------------------------
I've moved it up into common. I'll close this issue now.
> Refactor IoFilter life cycle management
> ---------------------------------------
>
> Key: DIRMINA-185
> URL: http://issues.apache.org/jira/browse/DIRMINA-185
> Project: Directory MINA
> Type: Improvement
> Reporter: Niklas Therning
> Priority: Minor
> Fix For: 0.9.4
>
> I thought it would be good to have this discussion in JIRA. Please add your thoughs to this issue. Below I'll try to give a background to the problem.
> Recently, a discussion on IoFilter life cycle management has been going on on the MINA mailing list. Questions have been raised whether MINA should provide life cycle management (LCM) for all filters (the current situation), if it should be optional (either on by default or off by default) or if it shouldn't be supported at all.
> In version 0.9.2 of MINA IoFilter has six LCM methods:
> init, onPreAdd, onPostAdd, onPreRemove, onPostRemove and destroy
> The LCM is handled by AbstractIoFilterChain and the singleton IoFilterLifeCycleManager. IoFilterLifeCycleManager uses reference counting to determine whether init/destroy should be called when a filter is added to/removed from a filter chain.
> In MINA 0.8 filter chains were typically shared among sessions. This meant that init/destroy would only be called once (or at least very few times) in the lifetime of an application. However, in MINA 0.9 filter chains are always per session which means that in some circumstances init/destroy will be called very frequently.
> The discussion on LCM forked from the discussion on DIRMINA-169. The LCM described above causes a deadlock in the current implementation of ThreadPoolFilter.
> How do you think MINA should handle LCM?
--
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
[jira] Commented: (DIRMINA-185) Refactor IoFilter life cycle
management
Posted by "peter royal (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-185?page=comments#action_12369019 ]
peter royal commented on DIRMINA-185:
-------------------------------------
ya, we should have a standard interface for things-with-lifecycle.
How about:
interface Startable {
void start() throws Exception;
void stop() throws Exception;
}
.. then it can also be re-used on other components that have a LC as well.
> Refactor IoFilter life cycle management
> ---------------------------------------
>
> Key: DIRMINA-185
> URL: http://issues.apache.org/jira/browse/DIRMINA-185
> Project: Directory MINA
> Type: Improvement
> Reporter: Niklas Therning
> Priority: Minor
>
> I thought it would be good to have this discussion in JIRA. Please add your thoughs to this issue. Below I'll try to give a background to the problem.
> Recently, a discussion on IoFilter life cycle management has been going on on the MINA mailing list. Questions have been raised whether MINA should provide life cycle management (LCM) for all filters (the current situation), if it should be optional (either on by default or off by default) or if it shouldn't be supported at all.
> In version 0.9.2 of MINA IoFilter has six LCM methods:
> init, onPreAdd, onPostAdd, onPreRemove, onPostRemove and destroy
> The LCM is handled by AbstractIoFilterChain and the singleton IoFilterLifeCycleManager. IoFilterLifeCycleManager uses reference counting to determine whether init/destroy should be called when a filter is added to/removed from a filter chain.
> In MINA 0.8 filter chains were typically shared among sessions. This meant that init/destroy would only be called once (or at least very few times) in the lifetime of an application. However, in MINA 0.9 filter chains are always per session which means that in some circumstances init/destroy will be called very frequently.
> The discussion on LCM forked from the discussion on DIRMINA-169. The LCM described above causes a deadlock in the current implementation of ThreadPoolFilter.
> How do you think MINA should handle LCM?
--
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
[jira] Commented: (DIRMINA-185) Refactor IoFilter life cycle
management
Posted by "peter royal (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-185?page=comments#action_12375692 ]
peter royal commented on DIRMINA-185:
-------------------------------------
Okay, would like to get some movement on this again.. How about:
init and destroy become start and stop (and remain on IoFilter interface)
IoFilterLCM goes away. Filters that want to start and stop whenever their reference count goes to 0 can use a wrapping filter that adds that behavior (MINA will provide), calling IoFilter.start/stop.
I think that encompasses what has been said in the comments..
> Refactor IoFilter life cycle management
> ---------------------------------------
>
> Key: DIRMINA-185
> URL: http://issues.apache.org/jira/browse/DIRMINA-185
> Project: Directory MINA
> Type: Improvement
> Reporter: Niklas Therning
> Priority: Minor
>
> I thought it would be good to have this discussion in JIRA. Please add your thoughs to this issue. Below I'll try to give a background to the problem.
> Recently, a discussion on IoFilter life cycle management has been going on on the MINA mailing list. Questions have been raised whether MINA should provide life cycle management (LCM) for all filters (the current situation), if it should be optional (either on by default or off by default) or if it shouldn't be supported at all.
> In version 0.9.2 of MINA IoFilter has six LCM methods:
> init, onPreAdd, onPostAdd, onPreRemove, onPostRemove and destroy
> The LCM is handled by AbstractIoFilterChain and the singleton IoFilterLifeCycleManager. IoFilterLifeCycleManager uses reference counting to determine whether init/destroy should be called when a filter is added to/removed from a filter chain.
> In MINA 0.8 filter chains were typically shared among sessions. This meant that init/destroy would only be called once (or at least very few times) in the lifetime of an application. However, in MINA 0.9 filter chains are always per session which means that in some circumstances init/destroy will be called very frequently.
> The discussion on LCM forked from the discussion on DIRMINA-169. The LCM described above causes a deadlock in the current implementation of ThreadPoolFilter.
> How do you think MINA should handle LCM?
--
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
[jira] Commented: (DIRMINA-185) Refactor IoFilter life cycle
management
Posted by "peter royal (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-185?page=comments#action_12368936 ]
peter royal commented on DIRMINA-185:
-------------------------------------
I would like to see the IoFilterLCM go away.
IoFilter's that want the current behavior can implement ref'counting themselves (via a decorator or abstract superclass).
> Refactor IoFilter life cycle management
> ---------------------------------------
>
> Key: DIRMINA-185
> URL: http://issues.apache.org/jira/browse/DIRMINA-185
> Project: Directory MINA
> Type: Improvement
> Reporter: Niklas Therning
> Priority: Minor
>
> I thought it would be good to have this discussion in JIRA. Please add your thoughs to this issue. Below I'll try to give a background to the problem.
> Recently, a discussion on IoFilter life cycle management has been going on on the MINA mailing list. Questions have been raised whether MINA should provide life cycle management (LCM) for all filters (the current situation), if it should be optional (either on by default or off by default) or if it shouldn't be supported at all.
> In version 0.9.2 of MINA IoFilter has six LCM methods:
> init, onPreAdd, onPostAdd, onPreRemove, onPostRemove and destroy
> The LCM is handled by AbstractIoFilterChain and the singleton IoFilterLifeCycleManager. IoFilterLifeCycleManager uses reference counting to determine whether init/destroy should be called when a filter is added to/removed from a filter chain.
> In MINA 0.8 filter chains were typically shared among sessions. This meant that init/destroy would only be called once (or at least very few times) in the lifetime of an application. However, in MINA 0.9 filter chains are always per session which means that in some circumstances init/destroy will be called very frequently.
> The discussion on LCM forked from the discussion on DIRMINA-169. The LCM described above causes a deadlock in the current implementation of ThreadPoolFilter.
> How do you think MINA should handle LCM?
--
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
[jira] Commented: (DIRMINA-185) Refactor IoFilter life cycle
management
Posted by "Niklas Therning (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-185?page=comments#action_12377738 ]
Niklas Therning commented on DIRMINA-185:
-----------------------------------------
The changes look great! Nice work Pete! One tiny little thing, shouldn't the wrapper be moved out from the support package? My impression has been that the support packages shouldn't be used by users, only internally by MINA. Right now the support packages aren't included in the generated Javadoc so most users won't even know about this class. Am I right?
> Refactor IoFilter life cycle management
> ---------------------------------------
>
> Key: DIRMINA-185
> URL: http://issues.apache.org/jira/browse/DIRMINA-185
> Project: Directory MINA
> Type: Improvement
> Reporter: Niklas Therning
> Priority: Minor
> Fix For: 0.9.4
>
> I thought it would be good to have this discussion in JIRA. Please add your thoughs to this issue. Below I'll try to give a background to the problem.
> Recently, a discussion on IoFilter life cycle management has been going on on the MINA mailing list. Questions have been raised whether MINA should provide life cycle management (LCM) for all filters (the current situation), if it should be optional (either on by default or off by default) or if it shouldn't be supported at all.
> In version 0.9.2 of MINA IoFilter has six LCM methods:
> init, onPreAdd, onPostAdd, onPreRemove, onPostRemove and destroy
> The LCM is handled by AbstractIoFilterChain and the singleton IoFilterLifeCycleManager. IoFilterLifeCycleManager uses reference counting to determine whether init/destroy should be called when a filter is added to/removed from a filter chain.
> In MINA 0.8 filter chains were typically shared among sessions. This meant that init/destroy would only be called once (or at least very few times) in the lifetime of an application. However, in MINA 0.9 filter chains are always per session which means that in some circumstances init/destroy will be called very frequently.
> The discussion on LCM forked from the discussion on DIRMINA-169. The LCM described above causes a deadlock in the current implementation of ThreadPoolFilter.
> How do you think MINA should handle LCM?
--
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
[jira] Commented: (DIRMINA-185) Refactor IoFilter life cycle
management
Posted by "Trustin Lee (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-185?page=comments#action_12377743 ]
Trustin Lee commented on DIRMINA-185:
-------------------------------------
yep my intention behind 'support' package is to indicate users that those classes are for internal use only. It would be nice if we can put it in common package?
> Refactor IoFilter life cycle management
> ---------------------------------------
>
> Key: DIRMINA-185
> URL: http://issues.apache.org/jira/browse/DIRMINA-185
> Project: Directory MINA
> Type: Improvement
> Reporter: Niklas Therning
> Priority: Minor
> Fix For: 0.9.4
>
> I thought it would be good to have this discussion in JIRA. Please add your thoughs to this issue. Below I'll try to give a background to the problem.
> Recently, a discussion on IoFilter life cycle management has been going on on the MINA mailing list. Questions have been raised whether MINA should provide life cycle management (LCM) for all filters (the current situation), if it should be optional (either on by default or off by default) or if it shouldn't be supported at all.
> In version 0.9.2 of MINA IoFilter has six LCM methods:
> init, onPreAdd, onPostAdd, onPreRemove, onPostRemove and destroy
> The LCM is handled by AbstractIoFilterChain and the singleton IoFilterLifeCycleManager. IoFilterLifeCycleManager uses reference counting to determine whether init/destroy should be called when a filter is added to/removed from a filter chain.
> In MINA 0.8 filter chains were typically shared among sessions. This meant that init/destroy would only be called once (or at least very few times) in the lifetime of an application. However, in MINA 0.9 filter chains are always per session which means that in some circumstances init/destroy will be called very frequently.
> The discussion on LCM forked from the discussion on DIRMINA-169. The LCM described above causes a deadlock in the current implementation of ThreadPoolFilter.
> How do you think MINA should handle LCM?
--
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