Using SEDA with existing synchronous code

I've been toying with the idea of making my company's federated search 
solution to be SEDA based. There are a couple of potential pitfalls that 
I'd like to explore with the more experienced users of SEDA:

1. We are using the (excellent) HTTPClient package from 
http://www.innovation.ch/java/HTTPClient/ (not to be confused with 
Jakarta's identically named project). This implementation uses synchronous 
sockets to implements its http client. Naturally, multiple threads are used 
to handle multiple connections .Porting the package to a SEDA based 
architecture (using asynchronous sockets) seems unfeasible. My question is 
-- how can I make this package live in peace with SEDA ? Should I use a 
dedicated stage for HTTP processing, that has N dedicated threads ? There 
is a clear warning in one of SEDA papers against implementing a stage that 
blocks. Should this warning be ignored ?

2. A similar issue is with our CORBA implementation (JacOrb) that manages 
its own threads, and I don't want (can't ?) change it. The problem is 
similar to the one above -- how should I implement this piece ?


Any input will be welcomed.

Cheers,
Shmul



-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5