hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship" <>
Subject RE: Registry
Date Thu, 03 Jun 2004 11:36:58 GMT
Removing dependencies has been very important to me. I've had personal experience involving
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
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
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 <> 

-----Original Message-----
From: Klaas Waslander [] 
Sent: Thursday, June 03, 2004 4:23 AM
Subject: RE: Registry

Quick question: it seems like commons-pool is not being used for these purposes? If that is
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
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
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
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 <> 

-----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
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
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
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
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 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
no really a complete solution since eventually we will need to expose some functionality through
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
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

Now for this EJBs to wrap business components we need some place to put the SS Registry where
all can access it... so we pretended to create the registry with an MBean and bind it on JNDI
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?

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
within an EAR, it works fine as a servlet context attribute.  Sharing between servers in a
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

-----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