John,
Yes, we do have our own VM (source is from
Sun) that knows how to plug into our SPC back
plane. Other VMs can communicate with the
PCA but, they do so using one of our VMs.
For instance, some of our customers run an
alternative VM for their Servlet engine. They
communicate to the SPC/PCA via an EJB
service layer.
I'm a curious as to why this would be a problem
for you?
Kirk
----- Original Message -----
From: "John Harby" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, February 09, 2001 8:28 PM
Subject: Re: Entity beans, clistering and scalability
> Kirk,
>
> I think this is very interesting but what I was wondering
> is could I just plug any VM into this architecture? It seems
> you're providing a parallelization of these VMs and unless
> I'm offbase I would think you need to modify the VM itself
> to support this type of IPC between the VMs. This may or may
> not be an issue for some but unfortunately would be a problem
> for us.
>
> Thanks,
> John Harby
>
>
>
> >From: Kirk Pepperdine <[EMAIL PROTECTED]>
> >Reply-To: A mailing list for Enterprise JavaBeans development
> ><[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: Re: Entity beans, clistering and scalability
> >Date: Fri, 9 Feb 2001 13:38:35 -0800
> >
> >----- Original Message -----
> >From: "Evan Ireland" <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>
> >Sent: Friday, February 09, 2001 6:04 AM
> >Subject: Re: Entity beans, clistering and scalability
> >
> >
> > > Jeff Schnitzer wrote:
> >
> >
> > > >
> > > > Pardon my (perhaps) naivete, but why on earth would starting
multiple
> > > > VMs on the same box increase scalability? It would seem like you're
> > > > just going to consume a lot of extra resources, when all you really
> > > > should need to do is start more threads.
> >[snip]
> > > >
> > > > Please tell me what I'm missing.
> >
> >Where should I start.... 8^)
> >
> >One of the steps in tuning a VM is to determine the maxumum number of
> >threads that it will support before performance bogs down. It will bog
> >down for a number of reasons to do with thread management. Depending
> >upon you're applications footprint on the VM, you'll typically see VM
> >performance degradation at about 70 threads. I believe that the number
of
> >VM threads is a tunable paramater in WL (which ties into their
clustering).
> >Gemstone/J also tried to control this but using a different mechanisum.
> >The other factor that affects performance is the size of the VM. These
> >two factors by them selves indicate that heavier applications will do
much
> >better if they utilize more than one VM. This corrolates well with my
> >experiences tuning EJB applications. FWIW, I've never seen a single VM
> >even come close to tapping out an E10K.
> >
> >From my vantage point, the vendors that are making scalability claims
> >support
> >multiple VM deployments. The question is, which mechanisums, work, are
> >easily configurable, easy to deploy, and really do offer a performance
> >advantage.
> >Oh and BTW, do they help with stability and avaliability. For instance,
if
> >you're
> >single VM blows, then what?
> >
> ><vendor>
> >I didn't use these tags in the previous paragraph because that was
straight
> >java stuff.
> >GemStone/J has the capability to launch several VM's on the same hardware
> >in the same ip space. It does this out of the box with no special
> >requirements
> >for hardware or software to support this functionality. I contend that
> >administrators
> >love this because, the can contain the entire application server on a
> >single
> >piece of
> >hardware if they so desire without setting up separate ip spaces. The VM
> >pool
> >sizes adapt to changes in the load on the system. A single VM/ip space
> >strategy
> >cannot dynamically add more ip spaces and consequently cannot dynamically
> >launch more
> >VMs.
> >GSJ's VM pooling also helps with stability and availability as old stale
> >VM's can
> >be rolled out of the system seamlessly. The application server can
support
> >different
> >versions of the same application running at the same time. This offers a
> >very flexible
> >migration possibilities. You can upgrade the application without having
to
> >take down
> >the system.
> >
> >Point is many of these things are easy because of how the systems
supports
> >multiple
> >VMs.
> ></vendor>
> >
> >Kirk
> >[EMAIL PROTECTED]
> >
>
>===========================================================================
> >To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> >of the message "signoff EJB-INTEREST". For general help, send email to
> >[EMAIL PROTECTED] and include in the body of the message "help".
> >
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
>
>
===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
