Costin Manolache wrote:
and certainly not
worth creating a new protocol. We need to pick one of
thrift/protobuf/hessian for
marshaling, and start doing some mux-ing in the protocol.
All those framework you mention are just helpers for
*building* the custom protocol. They actually mandate
tha
Kirk True wrote:
> Hi all,
>
> Can anyone suggest some trivial newbie projects for the Tomcat code
> base? I don't care how menial it is, typo changes, logging, testing
> (something specific), etc. I've been lurking on the list for awhile and
> want to start getting my hands dirty.
>
> Thanks,
>
On Sat, Apr 4, 2009 at 1:10 AM, Mladen Turk wrote:
> Costin Manolache wrote:
>
>>
>>> and certainly not
>>>
worth creating a new protocol. We need to pick one of
thrift/protobuf/hessian for
marshaling, and start doing some mux-ing in the protocol.
All those framework yo
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
On Sat, Apr 4, 2009 at 8:12 AM, Mladen Turk 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
>> prot
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 plat
On Sat, Apr 4, 2009 at 9:03 AM, David Jencks 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 messa
David Jencks wrote:
I don't really know what you guys are talking about
LOL. Not sure we do as well :)
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
Costin Manolache wrote:
On Sat, Apr 4, 2009 at 9:03 AM, David Jencks wrote:
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 som
On Sat, Apr 4, 2009 at 9:30 AM, Mladen Turk wrote:
> Costin Manolache wrote:
>
>> On Sat, Apr 4, 2009 at 9:03 AM, David Jencks
>> wrote:
>>
>>
>> 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
Hello, Dear All,
First, thank you very much for you valuable comments, Mark.
I've revised my project plan based on the comments of Mark, since I could
not edit my proposal any longer, I wrote the revised version of project plan
in a comment of my proposal, you can find it for certain by searc
On Apr 4, 2009, at 3:01 PM, Xie Xiaodong wrote:
Hello, Dear All,
First, thank you very much for you valuable comments, Mark.
I've revised my project plan based on the comments of Mark, since
I could
not edit my proposal any longer, I wrote the revised version of
project plan
in a commen
Thank you, David.
After having a glance at JSR-196 Specification, the intuitive of design
decision is to implement the built in auth methods (BASIC, DIGEST, FORM,
CLIENT_CERT) of Tomcat Valve with ServerAuthModule. And I agreed the
difficulty of implementing the auth function into filter you ment
Although the specification does not cover whether the *ServerAuthModule *should
be stateful or stateless, I think we'd better keep it stateless for
scalability.
2009/4/5 Xie Xiaodong
> Thank you, David.
>
> After having a glance at JSR-196 Specification, the intuitive of design
> decision is
Added:
tomcat/trunk/modules/tomcat-lite/test/org/apache/tomcat/test/watchdog/RfcDateParser.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/modules/tomcat-lite/test/org/apache/tomcat/test/watchdog/RfcDateParser.java?rev=762039&view=auto
=
Two Scenarios of thread per request :-
1- if the request send directly to server without filter:-
When a connection is idle between requests, the thread can be recycled, and the
connection is
placed in a centralized NIO select set to detect new
requests without consuming
16 matches
Mail list logo
