Re: [jboss-dev] Remoting 3.0

Hi Tim, Excellent. This is just the kind of feedback I was hoping for. We definitely want Remoting 3.0 to satisfy the needs of JBM. You're our best critics. :-) -Ron Tim Fox wrote: > Ron Sigal wrote: >> >> >> Scott M Stark wrote: >>> The main problem for me with the >>> TowardsGreaterSymmetryInRemoting page >>> is that its not talking about a base asynch message oriented >>> architecture. Much of the current asymmetry's is due to the rpc >>> oriented >>> api. If you flip this around to have a base asynch message view, >>> all >>> communication is handling of these messages. RPC with callbacks is >>> setting up blocking message handlers. Symmetry from a higher level >>> Client api is also not a requirement in my view. By definition a >>> callback is an unpredictable event/out of band msg with respect >>> to some >>> rpc call returning a value. The use of client and server are >>> also by >>> definition asymmetric and map to msg senders/receivers. We need >>> to start >>> from the bottom and move back up to the rpc api in order to be >>> able to >>> talk about what the 3.0 version of Client should look like. >> >> Actually, a "base asynch message oriented architecture" was just >> what I was trying to get at. While Remoting should continue to >> support the rpc model, the Connection.receive() and >> Connection.send() methods that I mentioned are intended to >> support asynchronous message sending and receiving. > Does Connection.receive() block until it receives a message()? > > Remoting 3.0 needs to support non-blocking semantics too to cope > with very large numbers of connection (We can't have a thread per > connection blocking on receive()). > > What you probably need is some kind of select() functionality (see > the Java NIO API or unix select() and poll()) where you can > register for events - in this case a single (or small group of) > thread(s) would register for events on multiple "channels" and are > woken up when an evens matches the selector. > > You probably also want to build in support for aynchronous IO via > callbacks - in this case, you don't even have thread(s) waiting on > select() but register some kind of callback handler and the OS > calls your handler directly - this can occur with less context > switching than select(). > >> Also, while it's true that client and server roles are inherently >> asymmetric, actors can play multiple roles (like Peter Sellers). >> In Remoting, for example, callbacks (in push mode) are handled by >> clients on the server side talking to servers on the client >> side. I think the same thing would be conceptually simpler with >> a "connection" abstraction that mirrors a real TCP connection: >> it's true that there are client and server sockets, but once the >> connection has been created, there can be senders and receivers >> on both sides. >> >>> The architecture also needs to be layered such that you can plug >>> into >>> low level message creation for the case of needing to control >>> the on the >>> wire format of these messages. >>> >>> We are brining on the MINA lead, Trustin Lee, so we will need to >>> look at >>> how >>> >>> >> >> The idea of stacks of marshallers and unmarshallers in Remoting >> has been floating around for a while, and Tom did some initial >> work in that direction. I'm thinking that's where the layered >> message handling will live. I've been meaning to write a second >> document on the subject, but, in fact, MINA has a pretty flexible >> and sophisticated framework for chains of message handlers, which >> looks like a good match for what we want. As you say, we need to >> understand how MINA and Remoting will work together. >> >>> Anil Saldhana wrote: >>> >>>> Ron, >>>> Most of it may already be present. >>>> >>>> Here is what I am thinking: >>>> a) Pluggable mechanism to do authentication at either ends of >>>> the pipes >>>> (SASL) >>>> b) Pluggable ways to secure the payload that passes through the >>>> pipes. >>>> >>>> Regards, >>>> Anil >>>> >>>> Ron Sigal wrote: >>>> >>>>> There have been various attempts to get some discussion going >>>>> about >>>>> the features desired for the next generation of Remoting, and >>>>> so far I >>>>> think the buzz has broken the -80 db level. I'm trying again >>>>> with the >>>>> wiki page at >>>>> http://wiki.jboss.org/wiki/Wiki.jsp? >>>>> page=TowardsGreaterSymmetryInRemoting. We in the Remoting >>>>> group (i.e., me in the Remoting group) would like >>>>> to hear from the Remoting stakeholders about what features >>>>> would make >>>>> Remoting more usable for you. Of course, I could just go >>>>> ahead and >>>>> write fun stuff. :-) >>>>> >>>>> -Ron >>>>> >>>> _______________________________________________ >>>> jboss-development mailing list >>>> jboss-development(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>> >>> >>> _______________________________________________ >>> jboss-development mailing list >>> jboss-development(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-development >>> >> -------------------------------------------------------------------- >> ---- >> >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development >> > > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development -- JBoss, a Division of Red Hat "My company's smarter than your company." _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development