hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Klaas Waslander" <>
Subject RE: Registry
Date Thu, 03 Jun 2004 08:23:17 GMT
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.
Klaas Waslander

-----Original Message-----
From: Howard M. Lewis Ship []
Sent: woensdag 26 mei 2004 16:49
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

Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind <> 

-----Original Message-----
From: Pablo Lalloni [] 
Sent: Wednesday, May 26, 2004 9:35 AM
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
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

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

-----Original Message-----
From: Pablo Lalloni [] 
Sent: Wednesday, May 26, 2004 8:38 AM
Subject: RE: Registry


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

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?

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,
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 :)


Naresh Sikha 

-----Original Message-----
From: Howard M. Lewis Ship [] 
Sent: Monday, May 24, 2004 11:37 AM
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
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

-----Original Message-----
From: Pablo Lalloni [] 
Sent: Monday, May 24, 2004 11:12 AM
Subject: Registry


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?


View raw message