You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@hivemind.apache.org by Klaas Waslander <K....@nl.tiscali.com> on 2004/06/03 10:23:17 UTC
RE: Registry
Quick question: it seems like commons-pool is not being used for these purposes? If that is correct, I'm curious to find out why.
One reason I'm asking is that commons-pool *is* a proven pooling technology, and is used in Tomcat's JDBC connection pooling which is very widely in use.
Thanks!
Klaas Waslander
-----Original Message-----
From: Howard M. Lewis Ship [mailto:hlship@comcast.net]
Sent: woensdag 26 mei 2004 16:49
To: hivemind-user@jakarta.apache.org
Subject: RE: Registry
HiveMind is very light weight; most of the standard issues that cause scaling concerns don't apply, because of the use of singletons rather than object pools.
If you stick to the singleton service model, then your code paths will not generally use any synchronized blocks or thread locals. Use of the the threaded and pooled service models does add overhead.
Invoking methods on a service is only slightly slower than invoking the methods directly on the core service implementation. Even when adding interceptors, the additional method calls are usually efficience instance method invocations, rather than the slower interface method invocations.
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
http://howardlewisship.com <http://howardlewisship.com/>
-----Original Message-----
From: Pablo Lalloni [mailto:plalloni@afip.gov.ar]
Sent: Wednesday, May 26, 2004 9:35 AM
To: hivemind-user@jakarta.apache.org
Subject: RE: Registry
El mié, 26-05-2004 a las 09:59, Howard M. Lewis Ship escribió:
If you are going to have two seperate HiveMind instnaces in the same JVM, the trick is to keep them seperated. In this case, you may not want to use the standard naming convention (that is, META-INF/hivemind.sdl ) but instead place your MDDs in specific places and use the RegistryBuilder to build a server- or client-registry just from the descriptors you want.
Depending on your app server and certain class loading issues, a simple public static variable may be the best way for your server-side components (EJBs and the like) to share the server-side Registry.
The current EJBProxyFactory expects that the EJB is a remote object; you'll need to put together a simple LocalEJBProxyFactory and make your EJBs local, for performance (and sanity!) reasons.
We already hacked out a LocalEJBProxyFactory and would gladly send a patch if you think it's useful.
Again, there's the question of whether you need EJBs at all? Today, for transactions, the EJBs are a good idea but HiveMind will shortly have an interceptor for managing transactions. Given that no body should use entity EJBs, and that session EJBs are subsumed by HiveMind, that leaves MDBs as the only real use for EJBs. If your solution doesn't use EJBs, and you can put together a transaction interceptor (or wait for me to write it), then you may not need two registries after all.
We can collaborate on implementing such TransactionInterceptor... if that's ok with you.
Still... how do you think that HiveMind will behave under such load? I mean in terms of pooling and threading... have you stressed it before?
The main reason exposed here for using EJBs with HiveMind components behind, was that we can rely on proven EJB container's pooling, threading, transaction, etc. and didn't know about this facet of HiveMind.
Of course I would be very very very happy if we can get rid of all those nasty EJBs ;)
Now for exposing functionality for other applications use... we will have to support EJB and WS, and JMX for mngmt also. Hence all this J2EE beasts will need access to the registry.
Other issue is the application lifecycle... creating the registry from an MBean allowed us to listen for start() and stop() events from the deployer so we could shutdown() the registry... if we put the registry on a static ¿how can we accomplish this behaviour? I mean... in a fancy way.
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
<http://howardlewisship.com/> http://howardlewisship.com
-----Original Message-----
From: Pablo Lalloni [mailto:plalloni@afip.gov.ar]
Sent: Wednesday, May 26, 2004 8:38 AM
To: hivemind-user@jakarta.apache.org
Subject: RE: Registry
Howard,
Your sight on this issues would be really appreciated.
Basically the problem is:
1. Integrating Tapestry 3 and HiveMind
2. Exposing components as EJB, MBean or WS
3. Using EJB-fronted components as a scalability solution
Even if we let the 3rd item aside I think having the registry just as a servlet context attribute is no really a complete solution since eventually we will need to expose some functionality through EJB or WS and manageability through JMX. Then how do we access the registry from those, since it is on a servlet context attribute?
About Tapestry-Hivemind integration I think would be a solution if could specify a helper-bean factory (which looks the bean up the registry) in a component or page spec, and maybe something similar for extensions.
I know the solution described below is not very elegant and rather awkward but we were unable to find any other.
Although the separation between "client" and "server" registries seems like a good idea, the integration between them doesn't look very straightforward.
Also I must mention that we expect vvvvery high load on this app. In the 10^4 magnitude of concurrent users.
What do you think?
El lun, 24-05-2004 a las 18:59, Pablo Lalloni escribió:
El lun, 24-05-2004 a las 18:29, Sikha, Naresh escribió:
Is the requirement:
1. Be able to use JNDI to find a Hivemind service in a single JVM?
This is what we're trying to implement...
Let me explain a little what we're trying to implement.
1. Business logic on components integrated by HiveMind ("server side")
2. Web app based on Tapestry ("client side")
We envision 2 HiveMind registries: one on "server side" (1) and one on "client side" (2).
Components built and exposed by (1) are wrapped with EJB (SLSB) which manage to lookup them in the (SS) Registry.
(2) is responsable (through an EJBLocalProxyFactory) of looking up those SLSB-EJB in JNDI and expose them as components to the Tapestry webapp which in turn looks them up using HiveMind registry (CS).
Now for this EJBs to wrap business components we need some place to put the SS Registry where they all can access it... so we pretended to create the registry with an MBean and bind it on JNDI where EJBs could get it.
This would be something like:
BusinessComponent ------------ "SS" Registry <--use--- WrapperEJB <---looks up---- "CS" Registry <---use---- WebApp
The WebApp use the CS Registry to get the EJBs which implements the same business interface as the business components registered in SS Registry. This would allow us to switch easily between using or not the EJB layer by just changing the registry where the webapp lookup business components.
We're using Tapestry 3.0 for the web app... there we face the problem of not having an elegant manner to inject EJB components on Tap components because we can't specify a factory for helper beans or application extensions.
Off course we could omit the EJB layer but that is a requirement given the scalability constraints we have on the application and considering the alpha state of HiveMind. Actually the "switching" ability was intended just for being able to stress test how HiveMind behaves under high load.
And yes, all of this is going to run on a single JVM...
Now, I know all this sounds awkward... but... any other ideas?
or
2. Be able to find the same reference to a Hivemind service across multiple JVMs?
I agree with Howard's take on (2). (1) is a bit more interesting. It is possible to define a custom JNDI protocol that could facade the most frequently occuring Hivemind service lookup, RegistryBuilder.constructDefaultRegistry().
By using a custom protocol you don't need to be serializable.
What would be such a custom protocol?
I'd be happy to contribute an implementation to (1).
Glad to read this :)
Cheers.
Naresh Sikha
-----Original Message-----
From: Howard M. Lewis Ship [mailto:hlship@comcast.net]
Sent: Monday, May 24, 2004 11:37 AM
To: hivemind-user@jakarta.apache.org
Subject: RE: Registry
Binding it into JNDI seems to go counter to the expressly single JVM nature of HiveMind. For sharing within an EAR, it works fine as a servlet context attribute. Sharing between servers in a cluster is the wrong approach ... instead, each server should have its own parallel Registry instance.
What with all the dynamic class creation and so forth, the Registry and the services, proxies, interceptors and so forth are bad candidate for serialization. It takes only a fraction of a second to construct the Registry. If you need to communicate between servers, use JMS.
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
<http://howardlewisship.com/> http://howardlewisship.com
-----Original Message-----
From: Pablo Lalloni [mailto:plalloni@afip.gov.ar]
Sent: Monday, May 24, 2004 11:12 AM
To: hivemind-user@jakarta.apache.org
Subject: Registry
Howard,
We're trying to bind a Registry on JNDI but as it's not Serializable we can't...
Any chances of make Registry extend Serializable?
Is this possible?
Or there's any reason for it to not be?
Cheers,
Pablo
RE: Registry
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
Removing dependencies has been very important to me. I've had personal experience involving Tapestry
where an excessive reliance on the commons libraries (and particular versions of those libraries,
particularily digester) has hindered adoption. Don't get me wrong ... when I'm personally building
an application, I reach for the commons stuff right away, but a framework is different. In fact, I
may (at some point) remove the dependency on werkz as well.
I have no doubt that the commons-pool implementation is better than HiveMind's, but pooling of
services in HiveMind is the exception, rather than the rule.
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
http://howardlewisship.com <http://howardlewisship.com/>
-----Original Message-----
From: Klaas Waslander [mailto:K.Waslander@nl.tiscali.com]
Sent: Thursday, June 03, 2004 4:23 AM
To: hivemind-user@jakarta.apache.org
Subject: RE: Registry
Quick question: it seems like commons-pool is not being used for these purposes? If that is correct,
I'm curious to find out why.
One reason I'm asking is that commons-pool *is* a proven pooling technology, and is used in Tomcat's
JDBC connection pooling which is very widely in use.
Thanks!
Klaas Waslander
-----Original Message-----
From: Howard M. Lewis Ship [mailto:hlship@comcast.net]
Sent: woensdag 26 mei 2004 16:49
To: hivemind-user@jakarta.apache.org
Subject: RE: Registry
HiveMind is very light weight; most of the standard issues that cause scaling concerns don't apply,
because of the use of singletons rather than object pools.
If you stick to the singleton service model, then your code paths will not generally use any
synchronized blocks or thread locals. Use of the the threaded and pooled service models does add
overhead.
Invoking methods on a service is only slightly slower than invoking the methods directly on the core
service implementation. Even when adding interceptors, the additional method calls are usually
efficience instance method invocations, rather than the slower interface method invocations.
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
http://howardlewisship.com <http://howardlewisship.com/>
-----Original Message-----
From: Pablo Lalloni [mailto:plalloni@afip.gov.ar]
Sent: Wednesday, May 26, 2004 9:35 AM
To: hivemind-user@jakarta.apache.org
Subject: RE: Registry
El mié, 26-05-2004 a las 09:59, Howard M. Lewis Ship escribió:
If you are going to have two seperate HiveMind instnaces in the same JVM, the trick is to keep them
seperated. In this case, you may not want to use the standard naming convention (that is,
META-INF/hivemind.sdl ) but instead place your MDDs in specific places and use the RegistryBuilder
to build a server- or client-registry just from the descriptors you want.
Depending on your app server and certain class loading issues, a simple public static variable may
be the best way for your server-side components (EJBs and the like) to share the server-side
Registry.
The current EJBProxyFactory expects that the EJB is a remote object; you'll need to put together a
simple LocalEJBProxyFactory and make your EJBs local, for performance (and sanity!) reasons.
We already hacked out a LocalEJBProxyFactory and would gladly send a patch if you think it's useful.
Again, there's the question of whether you need EJBs at all? Today, for transactions, the EJBs are a
good idea but HiveMind will shortly have an interceptor for managing transactions. Given that no
body should use entity EJBs, and that session EJBs are subsumed by HiveMind, that leaves MDBs as the
only real use for EJBs. If your solution doesn't use EJBs, and you can put together a transaction
interceptor (or wait for me to write it), then you may not need two registries after all.
We can collaborate on implementing such TransactionInterceptor... if that's ok with you.
Still... how do you think that HiveMind will behave under such load? I mean in terms of pooling and
threading... have you stressed it before?
The main reason exposed here for using EJBs with HiveMind components behind, was that we can rely on
proven EJB container's pooling, threading, transaction, etc. and didn't know about this facet of
HiveMind.
Of course I would be very very very happy if we can get rid of all those nasty EJBs ;)
Now for exposing functionality for other applications use... we will have to support EJB and WS, and
JMX for mngmt also. Hence all this J2EE beasts will need access to the registry.
Other issue is the application lifecycle... creating the registry from an MBean allowed us to listen
for start() and stop() events from the deployer so we could shutdown() the registry... if we put the
registry on a static ¿how can we accomplish this behaviour? I mean... in a fancy way.
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
<http://howardlewisship.com/> http://howardlewisship.com
-----Original Message-----
From: Pablo Lalloni [mailto:plalloni@afip.gov.ar]
Sent: Wednesday, May 26, 2004 8:38 AM
To: hivemind-user@jakarta.apache.org
Subject: RE: Registry
Howard,
Your sight on this issues would be really appreciated.
Basically the problem is:
1. Integrating Tapestry 3 and HiveMind
2. Exposing components as EJB, MBean or WS
3. Using EJB-fronted components as a scalability solution
Even if we let the 3rd item aside I think having the registry just as a servlet context attribute is
no really a complete solution since eventually we will need to expose some functionality through EJB
or WS and manageability through JMX. Then how do we access the registry from those, since it is on a
servlet context attribute?
About Tapestry-Hivemind integration I think would be a solution if could specify a helper-bean
factory (which looks the bean up the registry) in a component or page spec, and maybe something
similar for extensions.
I know the solution described below is not very elegant and rather awkward but we were unable to
find any other.
Although the separation between "client" and "server" registries seems like a good idea, the
integration between them doesn't look very straightforward.
Also I must mention that we expect vvvvery high load on this app. In the 10^4 magnitude of
concurrent users.
What do you think?
El lun, 24-05-2004 a las 18:59, Pablo Lalloni escribió:
El lun, 24-05-2004 a las 18:29, Sikha, Naresh escribió:
Is the requirement:
1. Be able to use JNDI to find a Hivemind service in a single JVM?
This is what we're trying to implement...
Let me explain a little what we're trying to implement.
1. Business logic on components integrated by HiveMind ("server side")
2. Web app based on Tapestry ("client side")
We envision 2 HiveMind registries: one on "server side" (1) and one on "client side" (2).
Components built and exposed by (1) are wrapped with EJB (SLSB) which manage to lookup them in the
(SS) Registry.
(2) is responsable (through an EJBLocalProxyFactory) of looking up those SLSB-EJB in JNDI and expose
them as components to the Tapestry webapp which in turn looks them up using HiveMind registry (CS).
Now for this EJBs to wrap business components we need some place to put the SS Registry where they
all can access it... so we pretended to create the registry with an MBean and bind it on JNDI where
EJBs could get it.
This would be something like:
BusinessComponent ------------ "SS" Registry <--use--- WrapperEJB <---looks up---- "CS" Registry
<---use---- WebApp
The WebApp use the CS Registry to get the EJBs which implements the same business interface as the
business components registered in SS Registry. This would allow us to switch easily between using or
not the EJB layer by just changing the registry where the webapp lookup business components.
We're using Tapestry 3.0 for the web app... there we face the problem of not having an elegant
manner to inject EJB components on Tap components because we can't specify a factory for helper
beans or application extensions.
Off course we could omit the EJB layer but that is a requirement given the scalability constraints
we have on the application and considering the alpha state of HiveMind. Actually the "switching"
ability was intended just for being able to stress test how HiveMind behaves under high load.
And yes, all of this is going to run on a single JVM...
Now, I know all this sounds awkward... but... any other ideas?
or
2. Be able to find the same reference to a Hivemind service across multiple JVMs?
I agree with Howard's take on (2). (1) is a bit more interesting. It is possible to define a custom
JNDI protocol that could facade the most frequently occuring Hivemind service lookup,
RegistryBuilder.constructDefaultRegistry().
By using a custom protocol you don't need to be serializable.
What would be such a custom protocol?
I'd be happy to contribute an implementation to (1).
Glad to read this :)
Cheers.
Naresh Sikha
-----Original Message-----
From: Howard M. Lewis Ship [mailto:hlship@comcast.net]
Sent: Monday, May 24, 2004 11:37 AM
To: hivemind-user@jakarta.apache.org
Subject: RE: Registry
Binding it into JNDI seems to go counter to the expressly single JVM nature of HiveMind. For sharing
within an EAR, it works fine as a servlet context attribute. Sharing between servers in a cluster
is the wrong approach ... instead, each server should have its own parallel Registry instance.
What with all the dynamic class creation and so forth, the Registry and the services, proxies,
interceptors and so forth are bad candidate for serialization. It takes only a fraction of a second
to construct the Registry. If you need to communicate between servers, use JMS.
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
<http://howardlewisship.com/> http://howardlewisship.com
-----Original Message-----
From: Pablo Lalloni [mailto:plalloni@afip.gov.ar]
Sent: Monday, May 24, 2004 11:12 AM
To: hivemind-user@jakarta.apache.org
Subject: Registry
Howard,
We're trying to bind a Registry on JNDI but as it's not Serializable we can't...
Any chances of make Registry extend Serializable?
Is this possible?
Or there's any reason for it to not be?
Cheers,
Pablo