Re: Application Clustering
Re: Application Clustering
- Subject: Re: Application Clustering
- From: Chuck Hill <email@hidden>
- Date: Mon, 10 Nov 2003 19:00:17 -0800
Karl,
At 08:50 PM 10/11/2003 -0500, Karl wrote:
>Thanks Jonathan.
>
>Session failover.
>
>The amount of data to share here is quite small. It is primarily
>within an Extranet application. So client-side cookies may be the way
>to go. Particularly since we can hide the individual hosts behind an
>appliance and there allow the cookies to be sent to whichever host
>services the request.
>
>For the notification mechanism, has anyone use JMS or Web Services for
>this?
>
The version of the change notification framework in Project Wonder is JMS
based.
>A very simple implementation is just to use a common DA url that one
>application calls on others - but that requires you to know which
>application instances are running. We were wondering whether there was
>some undocumented functionality within wotaskd which allows us to
>become aware of the status of running instances and then communicate
>with them accordingly.
>
wotaskd returns this information in HTML wrapped XML format (try
http://localhost:1085 for an example). It should not be too awful to parse
this. Otherwise you will have to roll your own registration scheme as
Arturo suggested.
>We hate excessive code - hence the reason we use WO.
>
:-)
Chuck
>On Nov 10, 2003, at 7:31 PM, email@hidden wrote:
>
>> [demime could not interpret encoding binary - treating as plain text]
>> On Mon, 10 Nov 2003 16:22:01 -0500 "Karl Gretton" wrote:
>>
>>> We are moving an application to a cluster of Xserve's running WO
>>> 5.2.2 under
>>> Panther Server. While WO does some application server / instance
>>> level load
>>> balancing, what facilities are available in the event of the failure
>>> of an
>>> instance?
>>
>> Essentially none.
>>
>>> Is there a session level failover API or some automatic functionality
>>> to
>>> maintain user state?
>>
>> No.
>>
>>> Also, we have extensive caching taking place within the application
>>> and also
>>> use shared editing contexts. Are there any automatic facilities for
>>> synchronizing cached objects or objects in a shared editing context?
>>> If
>>> not, does anyone have any particular thoughts on the best way to
>>> achieve
>>> this within WO?
>>
>> There are not any such automatic functionalities.
>>
>> There are a couple things to consider.
>>
>> 1) You want to maintain user state outside of the application instance
>> memory, so it can be restored from another instance even if the
>> instance
>> fails. The way to do this would be by writing your own WOSessionStore
>> that stored the WOSession and everything that came off it in some
>> external store (db or file system). Theoretically, that's possible,
>> and
>> some Apple documentation at least used to suggest this as a
>> possibility.
>> Practically.... I think it would require an awful lot of developer
>> hours
>> (with the developers behind them being relatively
>> knowledgable/experienced at WO) to make this work in general for any
>> component-action based application.
>>
>> The most challenging part is going to be about the page cache, storing
>> the page cache externally, and storing all the WOComponents (with
>> state)
>> in the page cache externally.
>>
>> If you can restrict your application to direct actions only, writing
>> this
>> external-storing WOSessionStore becomes much easier, and within the
>> realm
>> of possiblity. A DA-only app CAN still have a session. But it won't
>> have
>> a session page cache, so (I think!) you would only need to worry about
>> serializing any state information you have explicitly added to your
>> WOSession sub-class. That should be much more practical and
>> do-able----but writing a complex app with only Direct Actions can be a
>> pain. component based actions and stored component state gives you a
>> lot
>> of power for quickly and easily writing an app, that you lose if you
>> restrict yourself to only DAs (even with a session).
>>
>> 2. Your second question is "Are there any automatic facilities for
>> synchronizing cached objects or objects in a shared editing context?"
>> There are not, but... it doesn't seem to me that you would need to do
>> this to implement an instance failure/session-level failover. But I
>> could be missing something. Why do you think this would be neccesary?
>> One would need to think through the consequences of this NOT being
>> there
>> for session failover, but I'm not thinking of any problematic
>> consequences myself.
>>
>> If you DO need to implement this sort of thing, either for
>> session-failover purposes or other purposes, there is a Change
>> Notification framework in Project Wonder that would provide you with a
>> starting point. And possibly do everything you need right as it is,
>> depending on exactly what you need, I'm not sure what you need.
>>
>> --Jonathan
>>
>>
>>>
>>>
>>>
>>> In the past I have used EJB facilities (Message Beans) or simple SOAP
>>> calls
>>> to registered servers but this seems like a lot of work. Other app
>>> servers
>>> such as WebLogic and WebSphere have APIs for handling both of these
>>> features.
>>>
>>>
>>>
>>> Any thoughts would be welcome.
>>>
>>>
>>> Regards,
>>>
>>>
>>>
>>> Karl
>>> _______________________________________________
>>> webobjects-dev mailing list | email@hidden
>>> Help/Unsubscribe/Archives:
>>> http://www.lists.apple.com/mailman/listinfo/webobjects-dev
>>> Do not post admin requests to the list. They will be ignored.
>> _______________________________________________
>> webobjects-dev mailing list | email@hidden
>> Help/Unsubscribe/Archives:
>> http://www.lists.apple.com/mailman/listinfo/webobjects-dev
>> Do not post admin requests to the list. They will be ignored.
>_______________________________________________
>webobjects-dev mailing list | email@hidden
>Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
>Do not post admin requests to the list. They will be ignored.
>
--
Chuck Hill email@hidden
Global Village Consulting Inc. http://www.global-village.net
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.