Alexander Leyke wrote:
Hi,
A question about enhancement adoption process - how long does it
typically take for new code to show up in CVS, in nightly builds? What
is the verification process for new code? I have posted enhancement
request to the mailing list and to Bugzilla
(http://issues.apac
Alexander Leyke wrote:
Hi,
A question about enhancement adoption process - how long does it
typically take for new code to show up in CVS, in nightly builds? What
is the verification process for new code? I have posted enhancement
request to the mailing list and to Bugzilla
(http://issues.apac
Alexander Leyke wrote:
>
>
> Costin Manolache wrote:
>
>>Are you using the jni channel ? Is that working too ?
>>
>>
> No, it is the default ajp13 channel. I think I told you about my doubts
> about jk_workerEnv.c hardcoding "ajp13" as the type for all channel
> initialization. Anyway, this i
Costin Manolache wrote:
Are you using the jni channel ? Is that working too ?
No, it is the default ajp13 channel. I think I told you about my doubts
about jk_workerEnv.c hardcoding "ajp13" as the type for all channel
initialization. Anyway, this is how the code looks like now (let me kno
Alexander Leyke wrote:
>>I used BootstrapService because it didn't create the 8005 shutdown
>>socket. My tests were done with 4.0.
>>You can create your own wrapper, use CatalinaService directly or
>>call Bootstrap ( if you don't mind 8005 - in your case it doesn't
>>matter too much since you'll h
Costin Manolache wrote:
I used BootstrapService because it didn't create the 8005 shutdown
socket. My tests were done with 4.0.
You can create your own wrapper, use CatalinaService directly or
call Bootstrap ( if you don't mind 8005 - in your case it doesn't
matter too much since you'll have a s
Alexander Leyke wrote:
>>You can configure a different starter ( TomcatStarter did work
>>with an older version of BootstrapService - now you can't use
>>the 4.1 version of BS without daemon ). You can probably try
>>to just configure it to use o.a.catalina.startup.Bootstrap.
>>( or a different st
Costin Manolache wrote:
In jk2, all those strings are eliminated ( from C side ), we also eliminate
the buffer allocation ( we reuse the same jbyteArray and C array, with
code to eventually support NIO - that cuts 2 memcpy and few other small
things ). We also reduce the number of JNI calls to
Alexander Leyke wrote:
>>The JNI channel is special because it is single-threaded ( a doors channel
>>will use the same type of code ), and that has some implications in
>>how the request is processed - but the data encoding is the same.
>>
>>
> Does it mean that in-process worker is a performan
Thanks for the reply, Costin. There are some more questions below.
Costin Manolache wrote:
Ajp13 protocol ( marshalling, etc ) is used for in-process communication
and out of process communication. By marshalling the data we avoid some
expensive and complex JNI operations, and benefit of all opt
Alexander Leyke wrote:
> Costin Manolache wrote:
>
>>In jk2 we use ajp13 for all channels, including JNI. That allows us to
>>reuse the buffers and avoid object allocations from C - which improves a
>>lot the performance of the code ( we also avoid a lot of expensive calls,
>>etc ). Same techniqu
Costin Manolache wrote:
In jk2 we use ajp13 for all channels, including JNI. That allows us to reuse
the buffers and avoid object allocations from C - which improves a lot the
performance of the code ( we also avoid a lot of expensive calls, etc ).
Same technique is also used (AFAIK) in mozilla
Alexander Leyke wrote:
> "ajp13" worker factory seems to be hardcoded regardless of actual worker
> type. Here is a snippet from JTC-4.1.12/jk/native2/common/jk_workerEnv.c:
The reason is simple.
There are 2 "interfaces": protocol and channel. In jk1, the JNI used its own
protocol ( using Str
13 matches
Mail list logo
