geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: Eve integration with Geronimo
Date Fri, 10 Sep 2004 20:05:40 GMT
Hey Alex

 > From: Alex Karasulu <>
 > Also we have begun to separate out frontend plumbing from LDAP  
specific code in Eve's frontend.  This code is a TCP specific SEDA  
 > We're going to make this into a subproject on its own so we can reuse  
it for a Eve integrated Kerberos server without tight coupling (it can  
also be
 > standalone).  Trustin Lee (guy who did Netty) will be looking into  
adding UDP support to this in project.
 > So what does this all mean for integration?  Well we want to write  
wrappers for this SEDA framework where Eve just plugs in as another  
 > protocol to be able to benefit from those wrappers.  By writing a  
geronimo wrapper for SEDA rather than an Eve specific frontend we now  
allow any
 > protocol to be fired up within geronimo without having to  
specifically integrate that protocols frontend.  WDYT?
 > So we really want to write a SEDA framework wrapper intead of one  
specifically for Eve.  This also makes me think if its worth writting  
wrappers for the > backend of Eve and this raises several questions I  
still don't have answers to but these I'll leave for other emails.

I guess it depends what you mean by SEDA. Mostly I tend to think of the  
Channel abstraction in the concurrent.jar as being a pretty good  
abstraction for SEDA, where the channels can be local in VM or remote  
and you can put/take/poll objects - then the rest is just  
implementation details. Or some folks like to abstract away the low  
level SEDA like protocol of sync/async send behind a dynamic proxy to  
make SEDA invisible as it were. e.g. 

If what you mean is more of a SEDA based transport framework, well  
we've been working for quite some time on one of those on the ActiveMQ  
project :). Last benchmark we did was 22,000 messages/second sustained  
throughput on 2 2-way linux boxes with producer, broker, consumer all  
going across the network for 1-2K message sizes and reasonably low CPU  
usage (YMMV).

Currently we've transports for

* VM (in memory both sync & true SEDA)
* UDP & multicat
* NIO through g-networks and EmberIO
* JGroups
* HTTP (for tunnelling)
* Jabber (experimental)
* AIO4J (experimental)

In addition we have discovery protocols (Zeroconf & ActiveCluster) to  
make peer-style clusters of auto-discoverying clients & servers  
(Zeroconf is particularly cute as it works nice with Apple's  
Rendezvous), together with load balancing & fault tolerance transports  
(e.g. auto-fail over to another server in case of failure etc).

Other protocols to come are SOAP-over-TCP, FTP,  SMTP, SQL and file  
system when we get chance.

Details of the code are here...

Basically we have a really simple TransportChannel API which can  
represent any kind of transport protocol. 

The minimal contract we support for application protocols is that they  
must decide if a method call is sync (requiring a receipt such as a  
commit()) or async (fire & forget) and for async, whether a flush is  
required after the send. Consuming is pluggable based on the transport  
- so it decides if there is a thread, is it pull/push or how threads  
multiplex such as for NIO / AIO.

Most of the transport channels can be reused as is with a pluggable  
WireFormat which dictates how command objects (we use the Packet base  
class) get serialized on the wire. e.g. we have a default, fast as  
possible, wire format for the JMS Packets, as well as Jabber & XStream  
based ones etc.

The TransportChannel abstract represents about the 8th or 9th  
generation of this kind of abstraction the team have used over the last  
5 years or so for implementing high performance messaging & SEDA  
transport abstractions - so if nothing else, I'd advise you to go down  
a similar route of abstraction; then at the very least you'll be able  
to reuse our transports easily & we can easily plugin into your stuff -  
especially if you want to take advantage of our clustering, failover &  
replication protocols..


View raw message