geronimo-dev mailing list archives

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

 > From: Alex Karasulu <aok123@bellsouth.net>
 > Also we have begun to separate out frontend plumbing from LDAP  
specific code in Eve's frontend.  This code is a TCP specific SEDA  
framework.
 > 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  
simple
 > 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.

http://activemq.codehaus.org/maven/apidocs/org/codehaus/activemq/util/ 
AsyncProxy.html


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)
* TCP / SSL
* UDP & multicat
* NIO through g-networks and EmberIO
* JGroups
* JRMS
* JXTA
* 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...

http://activemq.codehaus.org/Code+Overview


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

http://activemq.codehaus.org/maven/apidocs/org/codehaus/activemq/ 
transport/package-summary.html


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

James
-------
http://radio.weblogs.com/0112098/


Mime
View raw message