On Sat, Apr 4, 2009 at 9:03 AM, David Jencks <david_jen...@yahoo.com> wrote:
> I don't really know what you guys are talking about but it might be you are > looking for a cross-platform multiplexing asynchronous message exchange > system. If so you might look into activemq's openwire transport. IIUC they > have a message grammar that is compiled into code for various platforms > including java, .net, c++, etc. > One more option to choose from - does anyone have experience with this ? How many dependencies, performance, etc ? My understanding of 'what we talk about' is what to do with mod_jk - deprecate/remove old code, add few features to better match current tomcat ( and current requirements - larger clusters, etc ). It seems there is some agreement that current AJP protocol won't work, but bigger disagreement on weather to just do nothing at all ( i.e. just maintain current code ), or do some small addition to AJP, use HTTP, etc. Costin > > thanks > david jencks > > > On Apr 4, 2009, at 8:42 AM, Costin Manolache wrote: > > On Sat, Apr 4, 2009 at 8:12 AM, Mladen Turk <mt...@apache.org> wrote: >> >> Costin Manolache wrote: >>> >>> So in essence you have a new protocol but the sole >>>> >>>>> difference is how you describe it. >>>>> >>>>> >>>>> >>>> The API can be something like: >>>> - legacyRequest(RequestMessage) - whatever we have in the current AJP >>>> protocol >>>> - getServerLoad() and whatever new we wanted to add >>>> >>>> Instead of defining AJP extensions, we just pick one of the marshalling >>>> libs >>>> and use them >>>> for encoding the new methods. >>>> >>>> >>>> Again, you are presuming a new protocol and IMO everyone >>> here are just getting nasty red spots on their faces when >>> you do such a thing ;) >>> >>> >> My understanding was that some people want to add features to mod_jk >> to support extended load balancing, eventually the fancy async stuff, etc. >> >> I can't see how this can be done without proto changes - current AJP won't >> work. >> And this is quite specific to tomcat, you can't dump it on incubator. >> >> What I'm trying to suggest is that a 'new protocol' ( as in - enhanced >> AJP, >> AJP2.0, etc ) >> is not a good idea. Instead the extensions needed should be done by using >> existing libraries and protocols, and when this is stable the AJP protocol >> should be >> deprecated (thus reducing the code size). Thrift/protobufs can be used >> quite >> easily >> on top of an existing transport, as payload, and can represent all the >> messages >> you want. >> >> >> Costin >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
