Loading...

hivemind-user@jakarta.apache.org

[Prev] Thread [Next]  |  [Prev] Date [Next]

RE: Registry Howard M. Lewis Ship Thu Jun 03 04:37:38 2004

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:[EMAIL PROTECTED] 
Sent: Thursday, June 03, 2004 4:23 AM
To: [EMAIL PROTECTED]
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:[EMAIL PROTECTED]
Sent: woensdag 26 mei 2004 16:49
To: [EMAIL PROTECTED]
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:[EMAIL PROTECTED] 
Sent: Wednesday, May 26, 2004 9:35 AM
To: [EMAIL PROTECTED]
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:[EMAIL PROTECTED] 
Sent: Wednesday, May 26, 2004 8:38 AM
To: [EMAIL PROTECTED]
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:[EMAIL PROTECTED] 
Sent: Monday, May 24, 2004 11:37 AM
To: [EMAIL PROTECTED]
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:[EMAIL PROTECTED] 
Sent: Monday, May 24, 2004 11:12 AM
To: [EMAIL PROTECTED]
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