Hi folks:
Thanks for the questions. I will try to respond (in line).
regards, Larry White
Nazrul Islam wrote:
> Thanks Larry and others for joining the discussion this morning. This
> was a very interesting topic.
>
> Here are some follow-up questions (to promote asynchronous discussions).
> - Please post the presentation to User Experience Wiki for future
> reference. Also, remember to take out the "confidential" message from
> the slide deck.
Yes, I have that on my todo list. I would like to update it a bit
because some of the info was a little
out-dated.
> - From the user experience perspective, requiring users to name server
> instances in a special way for in-memory replication feature is not a
> good thing (see slide 11). This gets very hard with large cluster
> where multiple server instances may be running on the same host. I
> think we need to fix this in v2.
I agree that it is not optimal. That is why we're planning to get this
in as soon as we can - schedule permitting.
> - With the location transparent design approach, we seem to be
> replicating the session twice in some cases (slide 18) to transfer
> ownership. Have we looked at how much time it takes to perform a
> failover? In other words, is there a benifit to our design approach?
There is benefit in our design approach. It is most important to
optimize performance for normal
(non-failover) scenarios which are close to 100% of the requests. We've
done that. For failover we do not replicate twice. We broadcast and
transfer the replica to the instance serving the request. Perhaps there
was something unclear in my preso that gave the impression of 2
replications.
> - I liked the zero configuration by default approch. Thanks!
Thank you. In early testing, it was quite nice to just start the DAS,
create a few instances, deploy an application for high-availability
('replicated') and just start using it enjoying the benefits of replication.
> - We ran out of time in the meeting. You mentioned about using a
> life-cycle module and properties. Could you please describe the
> configuration and how end user is expected to setup a cluster with
> in-memory replication support using CLI or GUI?
I'll try to address this in another email (or the preso) soon. We
provide a pluggable SPI for 3rd parties who want to provide their own
implementation of replication. They will configure their runtime
behavior in a LifeCycle they write, using name-value pair properties in
the LifeCycle module itself. There they will implement needed behavior
to start and stop their service - and they will register their own
'persistence-type' (e.g. com.mycompany.mypersistence-type) and associate
it with a BackingStoreFactory implementation they provide. More details
to come later about the SPI itself.
>
>--
>Nazrul Islam - (408) 276-6468 - Sun Microsystems, Inc.
>
>
> Nazrul Islam wrote:
>
>> Larry White will talk about the in-memory replication support for
>> GlassFish clustering introduced in v2. Please join us.
>>
>> Agenda:
>> Wednesday, Nov 08, 2006 - In-memory Replication (OnePager
>> <http://www.glassfishwiki.org/gfwiki/attach/OnePagersOrFunctionalSpecs/memory-replication-one-pager.html>,
>> Presentation) - Larry White
>>
>> Time:
>> 9 am - 10 am PDT
>>
>> Dial-in Info:
>> Toll Free Dial In Number: (866)545-5227
>> Int'l Access/Caller Paid Dial In Number:(865)673-6950
>> ACCESS CODE: 3535518
>>
>> Future Agenda:
>> http://www.glassfishwiki.org/gfwiki/Wiki.jsp?page=UserExperienceMeeting
>>
>>--
>>Nazrul Islam - (408) 276-6468 - Sun Microsystems, Inc.
>>
>>
>