Dear all,
In the past weeks, I have accumulated thoughts about potential new service
models that could be useful in HiveMind. I would like to share my thoughts
with you and possibly discuss if those models make sense, as well as discuss
possible implementation issues.
Some of these models come from an actual need that I have, for some others
these are just ideas.
1. prototype
This has already been discussed. Actually I am not convinced about the
interest of such a model, if I understood it clearly.
Actually, there is one unclear thing for me:
- is a new instance created for each method call to the service?
- is a new instance created when "looking up" the registry? (this would be
quite limited because it would require systematic lookup to work as
expected)
2. user
This is one model would be useful in one of my projects.
The idea is that each connected user has her own instance of the service.
The instance is created on first call from a new connected user, ant later
reused on each call from the same user.
Existing instances could be "auto-garbaged" after, for example, some amount
of time without any call (should be configurable).
This model requires extra work to store the current user in a ThreadLocal or
somewhere. This is easily done in a Servlet Container with a specific Filter
that gets the current user/principal from the user. I started working on
that as part of a more general "Security module" (providing authorization
checks).
Possibly, it could be interesting to define an additional interface that can
be implemented by the actual service implementation, enabling the instance
to be notified before it is garbaged.
3. session
The principle for this model looks quite like the "user" model. The idea is
to have an instance for each active session (session in the sense of
HttpSession).
The (sometimes subtle) difference with the "user" model is that one user can
have several sessions (either because he is connected twice to the Web
Server through 2 browser windows, or because you allow several persons to
log in to the system with the same login at the same time).
In this case, garbage collection of instances could be "triggered" by the
events related to HttpSession.
4. short-lived
I had this idea when thinking about integration of batch services (launched
by quartz jobs or some other scheduler mechanism) in HiveMind.
A service that is dedicated to batch processing is basically a singleton.
But generally, such a service may consume many resources (memory in
particular) that might not be recovered (memory leaks or other problem?)
when the batch is finished.
In this case, it could be useful to auto-garbage this service (the
implementation instance) after some configurable timeout.
Please note that we could partly have this behavior by using a "prototype"
model (but with a timeout value fixed to 0, ie immediate garbage after use).
Actually, I am not convinced of the interest of such a model, some feedback?
5. custom-pooled (or xpooled?)
This model we already discussed a few weeks ago. The idea was to have a
"real" pool of instances, with configurable params such as min, max,
increment, timeout...
The reason was to reduce the resource-consumption induced by HiveMind pooled
model after a heavy load (hundreds of threads because hundreds of
simultaneous users); in such case, the HiveMind pooled model retains
hundreds of service instances (even if the load has gone back to normal).
A few other notes:
For some of these models, it should be possible to implement them directly
based on HiveMind extensibility features for ServiceModels, without any
change to HiveMind itself.
However, for some models (in particular the "xpooled" model), there is the
need to specify arguments to the model in the <implementation> tag itself.
I already discussed that before (maybe I should put a JIRA evolution request
as well): I had the thought that we could use the same way that is used for
the configuration of translators, eg:
<invoke-factory model="xpooled,min=0,max=10">
...
Of course, we have other options (but they make the life of end-developers
harder) to provide those parameters to the ServiceModel, for instance, by
defining a configuration-point that includes the service-id using the
xpooled model with the additional parameters. But the implementation of the
service model would be a bit more complex, I think (maybe not so complex
with the new Map facilities for configuration-points, but unfortunately I
base my developments on HiveMind 1.0 until 1.1 is officially released), and
the configuration of the pool settings for the end developer is more
cumbersome, compare:
<contribution configuration-id="xpooled-config">
<service id="MyService" min="0" max="10"/>
</contribution>
<invoke-factory model="xpooled">
...
with the previous suggestion.
Comments or hints on this point?
Cheers
Jean-Francois
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
