Re: 5.3 CLOSE_WAIT problem and multi instance change notification
Re: 5.3 CLOSE_WAIT problem and multi instance change notification
- Subject: Re: 5.3 CLOSE_WAIT problem and multi instance change notification
- From: Chuck Hill <email@hidden>
- Date: Wed, 12 Oct 2005 11:26:54 -0700
On Oct 12, 2005, at 11:18 AM, Hordur Thordarson wrote:
<snip>
If they don't communicate the change with change notification
then the only ways I can see are the ones suggested by you/Apple:
- Timed invalidation via EO(F)'s fetch timestamps
This applies only to the first fetch/fault of an object into an
editing context or subsequent refaulting of particular objects.
Hmm, sounds like I need to re-read this. I was assuming that
functioned like so given a 60 minute refetch timeout:
- An app requests an EO for the first time and it gets fetched from
the db and gets the current timestamp
- 30 minutes later the app re-requests the EO and gets the cached
version from the object graph
- 2 hrs down the road the app re-requests again and EOF then goes
to the db again as the EO is over 60 minutes old in the cache
Am I misunderstanding this ?
Yes. :-) This has _nothing_ to do with the application. It only
applies to editing context's getting a copy of the data from the DB
snapshots and asking that it receive nothing older than X. Once the
EC has that copy of the data, the age of the data is not considered
again unless the object is re-faulted / invalidated. Creating new
ECs frequently and avoiding the long lived
session.defaultEditingContext() will result in much fresher data.
My test case is a CMS with a Direct Action based front end
(display) and a Component based back end (editing). If I'm
running two instances of the app and I open up two browser
windows, one displaying a page from the CMS and the other for
editing that page, then every time I refresh the DA page I'll
switch app instances due to round robin load balancing, so
sometimes I'll be looking at data from the same instance I'm
editing the page in which is easy to keep in sync, but sometimes
I'll be looking at data from the other app instance, which is
harder to keep fresh.
This scenario must occur fairly often in WO apps that allow
editing of their and it would be great to hear how people are
dealing with this.
Someone else (Ken?) already gave you my answer for this: a preview
URL. Keep the editor and preview in the same session so that they
see the same data. For regular viewers, they can get fresh data
when their session is created / when they first look at
something. After that, they see what they originally saw, the
information does not change on them as they browse. That may or
may not work for you.
Uti had some suggestioins and it sounds like the only way of doing
this is to make sure the preview url contains the same app number
and session id as the user's editing session. Unfortunately users
are not the easiest bunch of people to control so inevitably they
will first load a web page through the front end, and then go edit
it in another window in the backend (and possibly in another app
instance), and then they will scream when they refresh the original
page and their changes don't show up :-)
One word. Cookies. This is what cookies are for. They preserve
state without requiring URL changes. Cookies will ensure that the
front end and back end windows share the same instance and session.
Cookies are not evil. Cookies are your friend.
Chuck
On 11.10.2005, at 22:57, Chuck Hill wrote:
Hi,
On Oct 11, 2005, at 11:52 AM, Hordur Thordarson wrote:
Hi all,
I have a client who is running an app of mine on OSX Server
10.4 with WebObjects 5.3, and recently we've been having
significant problems with the app, probably as the load on the
app has been increasing.
Currently there is just 1 instance of the application running.
It will run fine for a while after being restarted, but then
the app will go into a state where according to top it has >
100 threads as opposed to around 40-70 normally, and it will
become unresponsive. Doing a netstat at this point in time
shows a lot of connections in a CLOSE_WAIT state and the only
way out is to kill the instance and restart the WebObjects
service.
Is anyone seeing anything like this with OSX Server 10.4 and WO
5.3 ?
Not normally, but your description of > 100 threads sounds like
it is deadlocked somewhere. Have you tried getting a thread dump?
Also, I was wondering if maybe running multiple instances would
help with this
Even having 40 - 70 threads in one instance says that you want
to be running multiple instances. That many threads indicates
that something is blocking / deadlocking or that that instance
is way overloaded.
and wanted to ask what people here are using for multi-instance
db change notification. I've read about Project Wonder's
ERChangeNotificationJMS and there is some old code from David
Neumann of Apple floating around but that's all I've been able
to find. Are you guys using ERChangeNotificationJMS or are you
using homegrown stuff for multi instance sync ?
ERChangeNotificationJMS is a modern version of David Neumann's
code. If I was going to use such a notification system that is
the one that I would choose. So far, I have not found it to be
necessary. You need to plan for object freshness and create new
editing contexts / do refreshing fetches to ensure that you have
data as fresh as you need it. You also need to take care of
optimistic locking conflicts, but those can also happen when
using a change notification system.
Chuck
--
Coming in 2006 - an introduction to web applications using
WebObjects and Xcode http://www.global-village.net/wointro
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve
specific problems. http://www.global-village.net/products/
practical_webobjects
--
Coming in 2006 - an introduction to web applications using
WebObjects and Xcode http://www.global-village.net/wointro
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve
specific problems. http://www.global-village.net/products/
practical_webobjects
--
Coming in 2006 - an introduction to web applications using WebObjects
and Xcode http://www.global-village.net/wointro
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems. http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden