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: Hordur Thordarson <email@hidden>
- Date: Wed, 12 Oct 2005 08:53:01 +0000
Hi Ute,
Yep, I have a preview button too. In the current single instance setup
it does not generate urls with an instance number however, but maybe
that will change if I add another instance ?
We are running 90% without session ids for the front end of the web.
We also use Apache url rewriting so we probably don't have instance
numbers in most of the DA urls either (I just took over support for
this CMS so I'm still learning).
Anyway, I'm going to try running with two instances with the
EOEditingContext's refetch time set to 60 seconds and see what happens.
Thanks,
Hörður Þ.
Lausn hugbúnaður ehf
Tel. +354-534-5005 / +354-699-1068
Web: http://www.lausn.is
On 12.10.2005, at 07:27, Ute Hoffmann wrote:
Hi,
I have such a CMS as well so what I do is: Have in the editing part
buttons to get a Preview/see what the user sees.
I use WOActionURL for that thus having Component Actions opening those
preview pages... keeping the session (and the instance).
DA's usually also have their instance in the URL and are sent back to
their instance, as long as they carry a session id at least (and are
created by WebObjects via the Direct Action binding of a Hyperlink
ect.). If you build your DA by hand/code you can insert the right
instance number by code.
Nevertheless data has a short life in my app, as I opt for as much
fresh data as possible.
Hope that helps,
Regards,
Ute
Am Mittwoch, 12.10.05 um 08:50 Uhr schrieb Hordur Thordarson:
Hi Chuck,
Thanks very much for your answers ! I promise I'll buy your book now
:-)
Just a few more questions:
1) At the risk of exposing my ignorance, how do I get a thread dump
from a running java app, preferably via Terminal ?
2) I've never really liked the idea of change notification to sync
app instances so your proposal sounds very good to me. And indeed
reading Apples EO documentation it appears they agree with you. (Btw,
their documentation has improved enormously since the last time I was
doing WO, 4-5 years ago !!).
So, how would you handle the simple (or not) case of two app
instances sharing a database and one instance updates an object and
some related objects that both have previously read and cached ?
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
- Always refreshing using refreshObject or setRefreshesFetchedObjects
- The bulldozer way, invalidateAllObjects
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.
Thanks again !
Hörður Þ.
Lausn hugbúnaður ehf
Tel. +354-534-5005 / +354-699-1068
Web: http://www.lausn.is
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
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
_______________________________________________
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