And what is the problem you are trying to solve ?

The old in-process' goal was speed - replacing marshalling with JNI. I don't
think it gained much.

I think app isolation/chrooting and clean versioning/reload are great goals
- but the model is
one app per process.

I fail to see use cases for having multiple webapps in different processes
on same machine, still sharing
directories. Is it to allow >4G heap ? 64bit VMs solve this. Scale ? Better
done  with more machines.
Maybe too many cores ?

Costin

On Thu, Mar 11, 2010 at 12:09 AM, Mladen Turk <mt...@apache.org> wrote:

> On 03/11/2010 08:50 AM, jean-frederic clere wrote:
>
>> On 03/11/2010 08:30 AM, Mladen Turk wrote:
>>
>>> On 03/11/2010 07:52 AM, Costin Manolache wrote:
>>>
>>>> On Wed, Mar 10, 2010 at 10:28 PM, Mladen Turk<mt...@apache.org>
>>>> wrote:
>>>>
>>>>  On 03/10/2010 11:10 PM, Costin Manolache wrote:
>>>>>
>>>>>  You want to have each webapp served by a different process ?
>>>>>> Or even different versions of a webapp in a different process ?
>>>>>>
>>>>>>
>>>>>>  First goal is to get rid of connectors and use Tomcat
>>>>> directly inside httpd or IIS or new Commons Runtime
>>>>> (replacing Tomcat Native and Daemon) I'm working on.
>>>>>
>>>>>
>>>> It used to work - about 10 years ago :-)
>>>>
>>>>
>>> Actually didn't. It worked for IIS and Httpd on windows
>>> only since at that time they had a single child process.
>>> Now IIS is the same as httpd with worker mpm.
>>>
>>> That was on of the reasons we kill JK2.
>>> JNI inproc connector simply didn't work.
>>>
>>
>> One of the big problem is that the prefork and worker models may use
>> several process for the same session and you can't fix a session to a
>> JVM process...
>>
>
> Sure. See the initial post. Session sharing is one
> of the things that has to be done.
> However this can be easily managed using shared memory
> or even using memcached
>
>
>
>  At the end you needed a flat cluster with one node for
>> each process and that doesn't scale.
>>
>>
> In essence it is a cluster, and that's why the subject title
> is 'reusing instances' since it lives in the same directory.
>
>
> Regards
> --
> ^TM
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Reply via email to