Re: Frameworks and Subcomponents
Re: Frameworks and Subcomponents
- Subject: Re: Frameworks and Subcomponents
- From: David Griffith <email@hidden>
- Date: Thu, 5 Nov 2009 12:12:43 +0100
Hi Kieran,
Thanks for your helpful tips, I have managed to solve the memory
problem. It was the addObjectToBothSidesOfRelationshipWithKey
problem. I had set some toMany relationships that weren't really
needed and I didn't realise the this method went so crazy on
faulting.... Now that I've modified the code, it's running super fast
again!
I still have not managed to deploy the app from Eclipse to my linux
box, but in the meantime I have managed to update the apps using Xcode
on Tiger so that at least they are functional for now.
Again, thanks. And thanks to everyone for their input.
Regards,
David.
On Nov 5, 2009, at 12:56 AM, Kieran Kelleher wrote:
FWIW, I tend to favor a couple of large instances rather than 20 small
ones. Just gives mush more breathing room for the natural high-low
swings
I would run a heavily used app with memory settings of the following
on java 1.5 32-bit.
-Xms512m -Xmx1536m
On Nov 4, 2009, at 6:13 PM, David Griffith wrote:
Yes, there are a few. One for example that would have 20-30,000
records on the toMany side when I look at it now. I don't know if
that should be toMany, or tooMany lol...
Anyway, I can clearly see where the problem is coming from now and I
don't think that actually I need the toMany relationship in those
cases. I made the mistake of automatically creating the reverse
relationships when in some circumstances they are really pointless.
60mb mightn't be much but when each instance is running up to 100mb
and they had a timeout of 24 hours.......
Regards,
David.
On Nov 5, 2009, at 12:05 AM, Kieran Kelleher wrote:
If the toMany side is too large (and I am talking 10's of
thousands), you may want a "single sided relationship").
Also, 60Mb is not much.
What is your memory allocation settings for the app in WOMonitor?
Kieran
On Nov 4, 2009, at 5:49 PM, David Griffith wrote:
I can't believe it. It's
addObjectsToBothSidesOfRelationshipWithKey that's causing the
problem. Faulting in massive datasets just to set a simple
relationship. I never knew about that. Going have to do some
serious work on this now.
I'll let you know how it goes, thanks so much for your help.
JConsole really helped a lot!
Regards,
David.
On Nov 4, 2009, at 6:06 PM, Kieran Kelleher wrote:
I forgot to say that you can run this command at the end of every
request, until you have fixed the problem, which means you are
regularly checking memory usage and forcing gc when it hits 90%.
just override Application.dispatchRequest and call super and put
this after the call to super.dispatch....
On Nov 4, 2009, at 11:57 AM, David Griffith wrote:
That's great Kieran, thanks. I really appreciate it. It's
actually my own app that we use internally, but no less serious as
our business is suffering because of it.
Regards,
David.
On 4 Nov 2009, at 17:48, Kieran Kelleher wrote:
As a "stop gap" or "safety net" or "give me breathing space" or a
"keep my customer from firing me while I figure this out", you
can use a class like the attached and call
WKRuntimeUtilities.forceGarbageCollectionIfNecessary()
.... which only gc's if you are above 90% of app memory.
Sometimes executing this brings app memory down close to where
it might be after launching initially, which buys you time to fix
the root cause. and you get a log.ERROR to notify you (if you
have log.error emails configured) that it actually did need to do
a gc.
HTH, Kieran
<WKRuntimeUtilities.java>
On Nov 4, 2009, at 11:34 AM, David Griffith wrote:
Excellent, the problem is that it is deployed on a Linux box and
as yet I haven't tried to reproduce the problem in development.
I'll try that tonight and see what happens. I have a fair idea
where the problems are occurring. Thanks for the below, it will
point me in the right direction to get started.
Regards,
David.
On 4 Nov 2009, at 17:18, Kieran Kelleher wrote:
Set maximum memory allocation for the app (1.5GB) ..... let me
know if u don't know how to do this. Then......
1) Get Wonder's request time recording going by putting this in
your app constructor:
setStatisticsStore(new ERXStatisticsStore());
this will tell you what the stack trace was before app fails
(assuming the request that causes out of memory is going to be
longer than 10 seconds)
2) Launch your app
3) Open terminal and type
jconsole
4) Go to jconsole memory graph view
5) Run the code until memory failure, monitoring the memory
graph to see if it suddenly jumps, increases with each
transaction and see if you can isolate what is causing memory
to grow (probably fetching too many objects)
....... see where you get with that first ........
Regards, Kieran
On Nov 4, 2009, at 10:57 AM, David Griffith wrote:
Ok, didn't realise it was a pay solution. Might be able to
find a way around that. Anyway, it is easily reproducible.
Every 30-50 transactions it falls on it's ass.
Dave.
On 4 Nov 2009, at 16:52, Kieran Kelleher wrote:
Hi David,
I will help you if I can, however I have not used JProfiler
(which is the best one by all accounts) because of the cost
and the fact that I have not yet found a problem where I had
to buy it to solve the problem.
A reproducible problem is easier to fix. If it only happens
occasionally in production, then we have to plant a few
things in your app to capture information .... and Wonder has
some of those features we need for deployment statistics.
Hopefully you use latest or recent Wonder.
if you are going to spend money, JProfiler might be a great
investment and just follow their tutorial videos.
Regards, Kieran
On Nov 4, 2009, at 8:47 AM, David Griffith wrote:
Interesting... I'll have a look at that.
Kieran, on another note, now that I have almost got my app
ported over to Eclipse, can I still take you up on your
offer of helping me to profile the memory usage? I'm going
to have a look through your emails now and see how I go
about getting the profiling tools etc. installed and maybe I
can do it myself but if I get stuck, would you be able to
help? I really have to nail this problem down and I've been
out of action for a couple of weeks since we last spoke
about it.
Kind regards,
David.
On Nov 4, 2009, at 2:44 PM, Kieran Kelleher wrote:
*I think you can* (well, has worked for me in the past
anyway) create an abstract component named "Wrapper" in the
framework so that your reusable page has no errors. IIRC,
the app *should* load the Application bundle component that
is similarly named "Wrapper" instead of the framework
component named "Wrapper" since app bundle is searched first
IIRC.
On Nov 4, 2009, at 7:39 AM, David Griffith wrote:
HI all,
I have a questions about reusable components in
frameworks. I've never done this before so please bear
with me.
I have an application, let's call it Distributor. This has
a component called Wrapper which is basically the page
wrapper I use for all pages.
I then have another component which I want to make more
reusable and which I would like to use in 3 different apps.
I have that component already put into a framework and that
seems fine. The problem is, the component used to contain
an element which referenced the Wrapper (so that everything
would be inside that). Clearly the 'Wrapper' can and will
be different for each application that I want to use it
in. What would be the normal procedure to do this?
I thought about having a component in my Distributor App
that would hold the reference to the Page Wrapper and
inside that would insert the shared component that I am
trying to use. Doing that I am getting the Page Wrapper
but just a blank page where I expect the component.
Any help would be appreciated.
Regards,
David.
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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