geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: RE: Eve integration with Geronimo
Date Sat, 11 Sep 2004 16:58:11 GMT
Hey James,

I'm still processing all this to see what we can use and how best we can integrate.  Thanks
for taking the time to write such a thorough email.  I'll get back to you shortly.


> From:
> Date: 2004/09/10 Fri PM 04:05:40 EDT
> To:
> Subject: RE:  Eve integration with Geronimo
> 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  
> 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.
> 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...
> Basically we have a really simple TransportChannel API which can  
> represent any kind of transport protocol.
> 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
> -------

View raw message