Thanks for the url, but I prefer to code my solution, spring must be good, but I don't like the big-swiss-knives framework, I have the feel to use a buldozer to take a flower...
My framemork will do a little bit more than rmi: - Object assigned to a client can be shared/pooled or other things (thanks to IoSession !) - Life cycle - Auto detection of serveur on network (broadcasting) - no need of registry. and so on. On 4/5/07, Maarten Bosteels <[EMAIL PROTECTED]> wrote:
On 4/5/07, yann Blazart <[EMAIL PROTECTED]> wrote: > > Thanks ! > > My use case is to provide a framework to make a replacement of Rmi for > internal use in entreprise (RAD) without the f... problems of registry > SecurityManager and codebase and Remote interface.... , based on Mina > (very > fun framework you've done !) If you just want a replacement for RMI you should take a look at the Spring Remoting options: http://www.springframework.org/docs/reference/remoting.html They make it very easy to remote a POJO and solve a lot of the problems of RMI. But if scalability is your main concern, MINA will probably be a better solution :-) Maarten I will try to improve my framework (called Roc), code a specific codec and > make a bench under heavy loading against Rmi, I will send to this list the > conclusions of my benches. > > Thanks a lot ! > > On 4/5/07, Vinod Panicker <[EMAIL PROTECTED]> wrote: > > > > On 4/5/07, yann Blazart <[EMAIL PROTECTED]> wrote: > > > Hi thanks for your answer, but I 've tried to set the tcpNoDelay to > > false on > > > each side and I didn't saw any really performance improvment. > > > The first problem is that if I test by only sending message but not > > waiting > > > for response, mina take 0.12 ms per call, aigainst Rmi that take 0.16ms > > per > > > call with the response. Is NIO slower than BIO, but more robust ? > > > > I guess you can say that NIO is more efficient that BIO in most cases. > > Usually servers need to handle lots of concurrent connections and > > that is where NIO really shines. In your use case, if you have just a > > single server and client and if there is no cpu starvation for the > > threads, it is not at all surprising to see better performance from > > BIO. In fact, due to recent OS level improvements, using a > > thread-per-connection model with BIO for a server seems to work pretty > > well for quite a few use cases. > > > > If your client and server are over the internet, do remember to factor > > in I/O wait times that will occur if you use BIO. If you can tell us > > what your use case is, we can provide better suggestions. > > > > HTH, > > Vinod. > > >
