Regarding point 2, there is an article here http://www-106.ibm.com/developerworks/java/library/j-dyn0603/ that compares the performance of reflection calls with direct calls. Which mirrors the dynamic proxy vs javassist proxy matter. The difference is significant (up to 100:1). But surely not directly transferable to a real world application.
I wouldn't worry too much about the overhead of some hundred proxy instances.
I've learned from hprof profiler, that between 20.000 and 50.000
object instances are created during the startup of a rather small hivemind
application. Furthermore the proxies and interceptors are rather small
in terms of bytecode and field numbers.
Achim Huegen
Am Sat, 27 Nov 2004 23:28:01 +0700 schrieb Jean-Francois Poilpret <[EMAIL PROTECTED]>:
Hi all,
1. Issue:
I just started working on the "user" service model described in my previous
mail, and I encountered some (small) issue:
My UserServiceModel class needs access to some external service. Since each
instance is constructed by my UserServiceModelFactory, my idea was to inject
that external service to the factory, and then pass it as an argument to the
constructor of UserServiceModel.
However, in HiveMind the ServiceModelFactory is not really a "service". It
is constructed directly by its default constructor and there is no
possibility (as far as I could see) to inject anything to it.
Of course, I have the option, in the UserServiceModelFactory, to get the
Registry and then get the service I need from it. But this is not very
"clean".
Is there any other way?
I had a look at the existing ServiceModels implementations in HiveMind, and
they all seem "self-contained" (ie, they do not require access to any
external service, EXCEPT the ShutdownCoordinator, but this one is directly
available from the ConstructableServicePoint passed to the factory).
If no other way exists, can this be a suitable evolution for HM1.1?
Regarding configuration, it would give something like:
<service-model name="..." service-id="..."/> Instead of (or in addition to): <service-model name="..." class="..."/>
I think this would be great so that we could say that "absolutely everything" in HM is a service! Currently we can say: "Almost everything" (which is not bad at all, by the way).
2. Wondering about proxies performance:
In HM we deal potentially with a big number of proxy classes.
In HM, they are all coded with Javassist, but we always have other options
for other developments, in particular the -much simpler- dynamic proxy from
the JDK.
I suppose that Javassist proxies are much faster than JDK dynamic proxies,
but my wonder is if this can be significant?
Are there comparisons figures between both techniques? And beyond the ratios
that can exist, is this really relevant (I mean if there is a 10:1 ratio,
but we are talking about 10:1ns, I would not consider it relevant for the
applications that I write).
I was also wondering about scalability issues related to proxies: as I said
before, in HM we deal with a big number of proxies (instances AND different
proxy classes); in a real-world application, having so many proxy classes
all over the place can be a problem or not?
For instance, if we take the following example:
- mid-size system with ~100 services (no primitive model)
- about 3 interceptors per service on average (eg: log, transaction,
authorization)
Each interceptor means 1 proxy class for each service
Each service has also 1 proxy class (generated by the ServiceModel)
So we end up with 400 Proxy classes in this system.
If we have only singleton services, this gives 1 instance for each Proxy, so
400 proxy instances.
(if we were using threaded or pooled, then each actual service instance
needs specific instances of interceptor proxies I think).
Here I take the hypothesis that most services are singleton, because in
threaded and pooled models the interceptor proxies.
Do we have systems that are used and run in such situations? Have there been
studies about the impact on memory consumption?
That will be all for today!
Cheers
Jean-Francois
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
