Re: Concurrent request handling
On May 24, 2011, at 10:50 PM, Кушнир Геннадий wrote:
> Hello
>
>>> How could that be that session is awaken by one thread and action is
>>> invoked by another within the same RRloop?
>>
>> Are you sure that is what is happening? Could it be that you have a bug in
>> your session's sleep() method that is sometimes causing the EC to NOT get
>> unlocked?
> public void sleep() {
> if(!isTerminating())
> ecLockManager.unlock();
> super.sleep();
> }
> I can't find any bug here ))
Not your problem, but a better way to write that is:
public void sleep() {
try {
if(!isTerminating())
ecLockManager.unlock();
} finally {
super.sleep();
}
}
>
>> Can you post the thread traces?
> 2011-05-2322:17:33INFOtX47k7Qn2z0d6CXNtlL4pw Attempting to
> lock editing context from WorkerThread14 that was previously locked in
> WorkerThread3
> java.lang.Exception: null
> [0] net.rujel.reusables.SessionedEditingContext.lock:118
> [30] net.rujel.reusables.SessionedEditingContext.saveChanges:73 // here
> super.saveChanges() is called
> [31] net.rujel.ui.LessonNoteEditor.save:412
> [32] net.rujel.ui.LessonNoteEditor.save:352
> [85] net.rujel.reusables.UTF8Application.dispatchRequest:46
> {java.lang.Exception: null
> [0] net.rujel.reusables.SessionedEditingContext.lock:118
> [1] net.rujel.reusables.MultiECLockManager.lock:66
> [2] net.rujel.Session.awake:118
> [9] net.rujel.reusables.UTF8Application.dispatchRequest:46}
> {}
Is the first trace, is this there?
> [1] net.rujel.reusables.MultiECLockManager.lock:66
> [2] net.rujel.Session.awake:118
It looks like you are somehow sharing editing contexts across sessions or using
a session's editing context in a non RR loop thread.
Chuck
> traces are filtered to include only my classes and recently active one
>
>
>> My first guess is that your EOEditingContext has a bug in it, and the
>> messages you are seeing are not valid.
>>
>>
>> Chuck
>
> I have looked through it a lot of times. And could not find any.
> Maybe you could?
>
> private String _nameOfLockingThread = null;
> private NSMutableArray _stackTraces = new NSMutableArray();
> private NSMutableArray _prevTraces = new NSMutableArray();
>
> public void lock() {
> String nameOfCurrentThread = Thread.currentThread().getName();
> // prepare filtered stack trace:
> String trace = WOLogFormatter.formatTrowable(new Exception());
> if (_stackTraces.count() == 0) {
> _stackTraces.addObject(trace);
> _nameOfLockingThread = nameOfCurrentThread;
> } else {
> if (nameOfCurrentThread.equals(_nameOfLockingThread)) {
> _stackTraces.addObject(trace);
> } else {
> logger.log(WOLogLevel.INFO,
> "Attempting to lock editing context from " + nameOfCurrentThread
> + " that was previously locked in " + _nameOfLockingThread,
> new Object[] {session,trace,_stackTraces,_prevTraces});
> }
> }
> super.lock();
> }
>
> public void unlock() {
> super.unlock();
> if (_stackTraces.count() > 0)
> _prevTraces.addObject(_stackTraces.removeLastObject());
> else
> _stackTraces.count();
> if (_stackTraces.count() == 0) {
> _nameOfLockingThread = null;
> _prevTraces.removeAllObjects();
> }
> }
>
> I think those methods consist of really simple statements that should not
> cause problems.
>
> ---
> Gennady Kushnir
--
Chuck Hill Senior Consultant / VP Development
Come to WOWODC this July for unparalleled WO learning opportunities and real
peer to peer problem solving! Network, socialize, and enjoy a great
cosmopolitan city. See you there! http://www.wocommunity.org/wowodc11/
smime.p7s
Description: S/MIME cryptographic signature
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Concurrent request handling
Hello
>> How could that be that session is awaken by one thread and action is
>> invoked by another within the same RRloop?
>
> Are you sure that is what is happening? Could it be that you have a bug in
> your session's sleep() method that is sometimes causing the EC to NOT get
> unlocked?
public void sleep() {
if(!isTerminating())
ecLockManager.unlock();
super.sleep();
}
I can't find any bug here ))
> Can you post the thread traces?
2011-05-23 22:17:33INFOtX47k7Qn2z0d6CXNtlL4pw Attempting to
lock editing context from WorkerThread14 that was previously locked in
WorkerThread3
java.lang.Exception: null
[0] net.rujel.reusables.SessionedEditingContext.lock:118
[30]net.rujel.reusables.SessionedEditingContext.saveChanges:73 // here
super.saveChanges() is called
[31]net.rujel.ui.LessonNoteEditor.save:412
[32]net.rujel.ui.LessonNoteEditor.save:352
[85]net.rujel.reusables.UTF8Application.dispatchRequest:46
{java.lang.Exception: null
[0] net.rujel.reusables.SessionedEditingContext.lock:118
[1] net.rujel.reusables.MultiECLockManager.lock:66
[2] net.rujel.Session.awake:118
[9] net.rujel.reusables.UTF8Application.dispatchRequest:46}
{}
traces are filtered to include only my classes and recently active one
> My first guess is that your EOEditingContext has a bug in it, and the
> messages you are seeing are not valid.
>
>
> Chuck
I have looked through it a lot of times. And could not find any.
Maybe you could?
private String _nameOfLockingThread = null;
private NSMutableArray _stackTraces = new NSMutableArray();
private NSMutableArray _prevTraces = new NSMutableArray();
public void lock() {
String nameOfCurrentThread = Thread.currentThread().getName();
// prepare filtered stack trace:
String trace = WOLogFormatter.formatTrowable(new Exception());
if (_stackTraces.count() == 0) {
_stackTraces.addObject(trace);
_nameOfLockingThread = nameOfCurrentThread;
} else {
if (nameOfCurrentThread.equals(_nameOfLockingThread)) {
_stackTraces.addObject(trace);
} else {
logger.log(WOLogLevel.INFO,
"Attempting to lock editing context from " + nameOfCurrentThread
+ " that was previously locked in " + _nameOfLockingThread,
new Object[] {session,trace,_stackTraces,_prevTraces});
}
}
super.lock();
}
public void unlock() {
super.unlock();
if (_stackTraces.count() > 0)
_prevTraces.addObject(_stackTraces.removeLastObject());
else
_stackTraces.count();
if (_stackTraces.count() == 0) {
_nameOfLockingThread = null;
_prevTraces.removeAllObjects();
}
}
I think those methods consist of really simple statements that should not cause
problems.
---
Gennady Kushnir
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Concurrent request handling
Hi, On May 24, 2011, at 1:38 AM, Gennady Kushnir wrote: > Hello again. > I did turn on concurrent request handling. And now I have some issue > with ec locking. > I have subclassed EOEditingContext and this subclass posts alerts to > the log when a thread attempts to lock ec that was already locked with > another thread. And now I have a log full of such messages. > I thought it was me to somehow make a mess to locking. But those log > messages contain stack traces. And they show that ec was locked by > MultiECLockManager on Session.awake() as it should have. And that the > thread is trying to lock ec when doing ec.saveChanges() which action > could not happen anywhere outside RRloop. > > How could that be that session is awaken by one thread and action is > invoked by another within the same RRloop? Are you sure that is what is happening? Could it be that you have a bug in your session's sleep() method that is sometimes causing the EC to NOT get unlocked? Can you post the thread traces? > Interesting thing is that users don't complain about deadlocks in App. > Also I can see in log that they continue working (in the same session) > after such issues. So I assume those issues don't cause deadlocks. > However users do complain that the App is running slow sometimes. > Maybe that is because of such "local" locks? My first guess is that your EOEditingContext has a bug in it, and the messages you are seeing are not valid. Chuck > 2011/3/10 Chuck Hill : >> >> On Mar 10, 2011, at 1:22 AM, Gennady Kushnir wrote: >> >>> Hello all ! >>> I am wondering whether to turn on concurrent request handling on my >>> deployment or not. >> >> I always have this on. >> >>> What are potential drawbacks of this? I assume there should be some. >>> Why would it be off by default otherwise? >>> I could not find anything interesting on this in documentation. >> >> WebObjects has several defaults that are not what most people would want. I >> think these defaults were set to preserve existing behavior when new >> features were added. Unless you are sharing unlocked global writable data >> (from static ivars or Application), there is no reason to NOT have this on. >> If you are sharing unlocked global writable data, then you are Bad Person >> and should fix this! >> >> >>> And another question: would concurrent request handling save me from >>> global application deadlocks when one single request locks on >>> exception? >> >> >> Maybe. It depends on why that session/request is deadlocking. I would >> focus on fixing that. >> >> >> Chuck >> >> -- >> Chuck Hill Senior Consultant / VP Development >> >> 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 >> >> >> >> >> >> >> >> > > > > -- > С уважением, > Геннадий Кушнир -- Chuck Hill Senior Consultant / VP Development Come to WOWODC this July for unparalleled WO learning opportunities and real peer to peer problem solving! Network, socialize, and enjoy a great cosmopolitan city. See you there! http://www.wocommunity.org/wowodc11/ smime.p7s Description: S/MIME cryptographic signature ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Concurrent request handling
Hello again. I did turn on concurrent request handling. And now I have some issue with ec locking. I have subclassed EOEditingContext and this subclass posts alerts to the log when a thread attempts to lock ec that was already locked with another thread. And now I have a log full of such messages. I thought it was me to somehow make a mess to locking. But those log messages contain stack traces. And they show that ec was locked by MultiECLockManager on Session.awake() as it should have. And that the thread is trying to lock ec when doing ec.saveChanges() which action could not happen anywhere outside RRloop. How could that be that session is awaken by one thread and action is invoked by another within the same RRloop? Interesting thing is that users don't complain about deadlocks in App. Also I can see in log that they continue working (in the same session) after such issues. So I assume those issues don't cause deadlocks. However users do complain that the App is running slow sometimes. Maybe that is because of such "local" locks? Gennady Kushnir 2011/3/10 Chuck Hill : > > On Mar 10, 2011, at 1:22 AM, Gennady Kushnir wrote: > >> Hello all ! >> I am wondering whether to turn on concurrent request handling on my >> deployment or not. > > I always have this on. > >> What are potential drawbacks of this? I assume there should be some. >> Why would it be off by default otherwise? >> I could not find anything interesting on this in documentation. > > WebObjects has several defaults that are not what most people would want. I > think these defaults were set to preserve existing behavior when new features > were added. Unless you are sharing unlocked global writable data (from > static ivars or Application), there is no reason to NOT have this on. If you > are sharing unlocked global writable data, then you are Bad Person and should > fix this! > > >> And another question: would concurrent request handling save me from >> global application deadlocks when one single request locks on >> exception? > > > Maybe. It depends on why that session/request is deadlocking. I would focus > on fixing that. > > > Chuck > > -- > Chuck Hill Senior Consultant / VP Development > > 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 (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Concurrent request handling
Thanks for this. I'm doing a quick code review! b/w Mark On 5 April 2011 18:48, Chuck Hill wrote: > Hi Mark, > > On Apr 4, 2011, at 11:20 PM, Mark Wardle wrote: > >> Hi all, >> >> There have been a number of threads discussing this runtime option. I >> think the consensus opinion was that although it is off by default, it >> is better switched on. > > I think it is off by default to match the previous (now ancient) > functionality. > > >> Presumably there are some basic additional rules to follow. > > The EOF Commandments (as usual) plus: > > Don't Do Stupid Things > > > >> For instance, AFAIK components will not be shared by multiple threads >> as they will be instantiated as one goes along or will be returned >> from the page cache as part of a single session - and as one session >> will be handled by only one thread, this is fine. How does concurrent >> handling interact with stateful and stateless components? > > Stateful are always session specific so safe by design. Stateless are also > safe, transparently, see Practical WebObjects for the details if you want. > > >> Perhaps more of an issue is that code within my EOF classes may be >> executed by more than one thread at a time. I use lazy initialisation >> but there is a race condition there. Fortunately, most of the time >> there are no side-effects and running that code twice would have no >> significant deleterious effect. For situations where it would matter I >> would assume protecting lazy initialisation with a double check and a >> synchronised block for the inner check would be fine? Is that >> interpretation correct? > > I think that synchronised is what you want. > > >> Are there other commandments? > > > Don't Do Stupid Things :-) Which boils down to don't share objects that are > not thread-safe, or writable data, at the global level unless you have > appropriate protection. Global being either static members or instance > variables on your application. Shared, non-thread safe formatters are a > common mistake. > > > Chuck > > > -- > Chuck Hill Senior Consultant / VP Development > > 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 > > > > > > > > -- Dr. Mark Wardle Specialist registrar, Neurology Cardiff, UK ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Concurrent request handling
Hi Xavier; I would probably add accessors to the superclass and then have a helper singleton to actually cache and factory them into the WOContext, but it depends on your application design as to what will work best. Hope this helps. cheers. That means I would have as much formatter instances as there's a request for a specific component/page. It's probably not a big deal, it just feels strange to me to have something that is application-wide used in a component part. Would it be a better practice to implement those formatter in a component super-class or have them as an interface for the components that need them? -- Andrew Lindesay www.silvereye.co.nz ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Concurrent request handling
On Apr 7, 2011, at 8:09 AM, Dev WO wrote: > Hello Andrew, > >> >> Hi Xavier; >> >> I would suggest not putting the formatter in the EO class because the EO is >> model layer and the formatter really belong as part of the display logic -- >> blurring the two eventually ends up causing design problems in the long-haul. > > I completely agree with this:) > >> I think in the past when faced with this situation, I added accessors to the >> components' controllers' super-class which then "gets or creates" a >> formatter for a particular purpose (data quantity format / timestamp / >> currency etc...) which is cached in the "user info" in the WOContext >> instance for the current request-response cycle. This approach allows you >> to re-use the formatters for the request-response cycle and then just allows >> them to be garbage collected at the end of the cycle. > > That means I would have as much formatter instances as there's a request for > a specific component/page. It's probably not a big deal, it just feels > strange to me to have something that is application-wide used in a component > part. A compared to String or Integer or... :-) Formatters should be lightweight objects that can be created, used, and discarded at will. Caching and re-using them is just an easy and obvious optimization. Also, some formatters ARE thread safe. It is the date formatting ones that seem to be a problem. > Would it be a better practice to implement those formatter in a component > super-class or have them as an interface for the components that need them? They would have to be static to be in an interface and that is not thread safe. :-) I'd do what Andrew suggests or just create what you need in your component constructor. If it is a stateless app, just keep the page cache very small and you don't have to worry about memory. Chuck >> cheers. >> >>> Sorry to jump into this to add another question:) >>> But I would have expected the formatter to not be an issue as it's not >>> actually writing data. >>> If you have a stateless app (like full of DA), how would you handle that >>> as you can actually put the formatter in Session? >>> Do you have to put the formatter inside the EO class? >> >> -- >> Andrew Lindesay >> www.silvereye.co.nz >> ___ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40anazys.com >> >> This email sent to webobje...@anazys.com >> > > ___ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net > > This email sent to ch...@global-village.net -- Chuck Hill Senior Consultant / VP Development 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 smime.p7s Description: S/MIME cryptographic signature ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Concurrent request handling
Hello Andrew, > > Hi Xavier; > > I would suggest not putting the formatter in the EO class because the EO is > model layer and the formatter really belong as part of the display logic -- > blurring the two eventually ends up causing design problems in the long-haul. I completely agree with this:) > I think in the past when faced with this situation, I added accessors to the > components' controllers' super-class which then "gets or creates" a formatter > for a particular purpose (data quantity format / timestamp / currency etc...) > which is cached in the "user info" in the WOContext instance for the current > request-response cycle. This approach allows you to re-use the formatters > for the request-response cycle and then just allows them to be garbage > collected at the end of the cycle. That means I would have as much formatter instances as there's a request for a specific component/page. It's probably not a big deal, it just feels strange to me to have something that is application-wide used in a component part. Would it be a better practice to implement those formatter in a component super-class or have them as an interface for the components that need them? Thanks, Xavier > > cheers. > >> Sorry to jump into this to add another question:) >> But I would have expected the formatter to not be an issue as it's not >> actually writing data. >> If you have a stateless app (like full of DA), how would you handle that >> as you can actually put the formatter in Session? >> Do you have to put the formatter inside the EO class? > > -- > Andrew Lindesay > www.silvereye.co.nz > ___ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40anazys.com > > This email sent to webobje...@anazys.com > ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Concurrent request handling
Hi Xavier; I would suggest not putting the formatter in the EO class because the EO is model layer and the formatter really belong as part of the display logic -- blurring the two eventually ends up causing design problems in the long-haul. I think in the past when faced with this situation, I added accessors to the components' controllers' super-class which then "gets or creates" a formatter for a particular purpose (data quantity format / timestamp / currency etc...) which is cached in the "user info" in the WOContext instance for the current request-response cycle. This approach allows you to re-use the formatters for the request-response cycle and then just allows them to be garbage collected at the end of the cycle. cheers. Sorry to jump into this to add another question:) But I would have expected the formatter to not be an issue as it's not actually writing data. If you have a stateless app (like full of DA), how would you handle that as you can actually put the formatter in Session? Do you have to put the formatter inside the EO class? -- Andrew Lindesay www.silvereye.co.nz ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Concurrent request handling
Hello Chuck,
Sorry to jump into this to add another question:)
But I would have expected the formatter to not be an issue as it's not actually
writing data.
If you have a stateless app (like full of DA), how would you handle that as you
can actually put the formatter in Session?
Do you have to put the formatter inside the EO class?
Thanks,
Xavier
On 5 avr. 2011, at 20:17, Chuck Hill wrote:
> Hi Matteo,
>
> I don't think that will cause a deadlock. It will cause some incorrectly
> formatted input / output. The easiest fix is to move this from Application
> to Session and adjust the bindings.
>
> As for the lockups, you really need to get thread dumps to assess those.
> jstack is an easy way to do this.
>
>
> Chuck
>
>
> On Apr 5, 2011, at 11:12 AM, Matteo Centro wrote:
>
>> Hi Chuck,
>>
>> could you elaborate more on the shared formatters thing?
>>
>>> Don't Do Stupid Things :-) Which boils down to don't share objects that
>>> are not thread-safe, or writable data, at the global level unless you have
>>> appropriate protection. Global being either static members or instance
>>> variables on your application. Shared, non-thread safe formatters are a
>>> common mistake.
>>
>> we inherited a project that has random (but infrequent) lockups and I found
>> that in the Application.java
>>
>> first there is an instance variable
>>
>> private NSNumberFormatter millionsFormatter;
>>
>> then a lazy initialization in the accessor method:
>>
>> public NSNumberFormatter millionsFormatter() {
>> if (millionsFormatter ==null) {
>> millionsFormatter = new NSNumberFormatter();
>> millionsFormatter.setPattern("###,##0.00");
>> millionsFormatter.setDecimalSeparator(",");
>> millionsFormatter.setThousandSeparator(".");
>> }
>> return millionsFormatter;
>> }
>>
>> Could this approach be one of the causes of the lockups? The app runs in
>> multithreaded mode and there are tons of components with WOStrings bound to
>> this formatter...
>>
>> Thanks,
>>
>>
>> Matteo
>>
>
> --
> Chuck Hill Senior Consultant / VP Development
>
> 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 (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40anazys.com
>
> This email sent to webobje...@anazys.com
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Concurrent request handling
Hi Chuck,
there are 30 different formatters (all NS...) in the application and more than
500 WOComponents. if this is not a potential deadlock case, I'll leave them
there... Too lazy!
I'll try to investigate the deadlocks properly, the problem is that they're
very rare and almost impossible to reproduce in our test environment.
Thanks,
Matteo
On 05/apr/2011, at 20.17, Chuck Hill wrote:
> Hi Matteo,
>
> I don't think that will cause a deadlock. It will cause some incorrectly
> formatted input / output. The easiest fix is to move this from Application
> to Session and adjust the bindings.
>
> As for the lockups, you really need to get thread dumps to assess those.
> jstack is an easy way to do this.
>
>
> Chuck
>
>
> On Apr 5, 2011, at 11:12 AM, Matteo Centro wrote:
>
>> Hi Chuck,
>>
>> could you elaborate more on the shared formatters thing?
>>
>>> Don't Do Stupid Things :-) Which boils down to don't share objects that
>>> are not thread-safe, or writable data, at the global level unless you have
>>> appropriate protection. Global being either static members or instance
>>> variables on your application. Shared, non-thread safe formatters are a
>>> common mistake.
>>
>> we inherited a project that has random (but infrequent) lockups and I found
>> that in the Application.java
>>
>> first there is an instance variable
>>
>> private NSNumberFormatter millionsFormatter;
>>
>> then a lazy initialization in the accessor method:
>>
>> public NSNumberFormatter millionsFormatter() {
>> if (millionsFormatter ==null) {
>> millionsFormatter = new NSNumberFormatter();
>> millionsFormatter.setPattern("###,##0.00");
>> millionsFormatter.setDecimalSeparator(",");
>> millionsFormatter.setThousandSeparator(".");
>> }
>> return millionsFormatter;
>> }
>>
>> Could this approach be one of the causes of the lockups? The app runs in
>> multithreaded mode and there are tons of components with WOStrings bound to
>> this formatter...
>>
>> Thanks,
>>
>>
>> Matteo
>>
>
> --
> Chuck Hill Senior Consultant / VP Development
>
> 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 (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Concurrent request handling
Hi Matteo,
I don't think that will cause a deadlock. It will cause some incorrectly
formatted input / output. The easiest fix is to move this from Application to
Session and adjust the bindings.
As for the lockups, you really need to get thread dumps to assess those.
jstack is an easy way to do this.
Chuck
On Apr 5, 2011, at 11:12 AM, Matteo Centro wrote:
> Hi Chuck,
>
> could you elaborate more on the shared formatters thing?
>
>> Don't Do Stupid Things :-) Which boils down to don't share objects that
>> are not thread-safe, or writable data, at the global level unless you have
>> appropriate protection. Global being either static members or instance
>> variables on your application. Shared, non-thread safe formatters are a
>> common mistake.
>
> we inherited a project that has random (but infrequent) lockups and I found
> that in the Application.java
>
> first there is an instance variable
>
> private NSNumberFormatter millionsFormatter;
>
> then a lazy initialization in the accessor method:
>
> public NSNumberFormatter millionsFormatter() {
> if (millionsFormatter ==null) {
> millionsFormatter = new NSNumberFormatter();
> millionsFormatter.setPattern("###,##0.00");
> millionsFormatter.setDecimalSeparator(",");
> millionsFormatter.setThousandSeparator(".");
> }
> return millionsFormatter;
> }
>
> Could this approach be one of the causes of the lockups? The app runs in
> multithreaded mode and there are tons of components with WOStrings bound to
> this formatter...
>
> Thanks,
>
>
> Matteo
>
--
Chuck Hill Senior Consultant / VP Development
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
smime.p7s
Description: S/MIME cryptographic signature
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Concurrent request handling
Hi Chuck,
could you elaborate more on the shared formatters thing?
> Don't Do Stupid Things :-) Which boils down to don't share objects that are
> not thread-safe, or writable data, at the global level unless you have
> appropriate protection. Global being either static members or instance
> variables on your application. Shared, non-thread safe formatters are a
> common mistake.
we inherited a project that has random (but infrequent) lockups and I found
that in the Application.java
first there is an instance variable
private NSNumberFormatter millionsFormatter;
then a lazy initialization in the accessor method:
public NSNumberFormatter millionsFormatter() {
if (millionsFormatter ==null) {
millionsFormatter = new NSNumberFormatter();
millionsFormatter.setPattern("###,##0.00");
millionsFormatter.setDecimalSeparator(",");
millionsFormatter.setThousandSeparator(".");
}
return millionsFormatter;
}
Could this approach be one of the causes of the lockups? The app runs in
multithreaded mode and there are tons of components with WOStrings bound to
this formatter...
Thanks,
Matteo
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Concurrent request handling
Hi Mark, On Apr 4, 2011, at 11:20 PM, Mark Wardle wrote: > Hi all, > > There have been a number of threads discussing this runtime option. I > think the consensus opinion was that although it is off by default, it > is better switched on. I think it is off by default to match the previous (now ancient) functionality. > Presumably there are some basic additional rules to follow. The EOF Commandments (as usual) plus: Don't Do Stupid Things > For instance, AFAIK components will not be shared by multiple threads > as they will be instantiated as one goes along or will be returned > from the page cache as part of a single session - and as one session > will be handled by only one thread, this is fine. How does concurrent > handling interact with stateful and stateless components? Stateful are always session specific so safe by design. Stateless are also safe, transparently, see Practical WebObjects for the details if you want. > Perhaps more of an issue is that code within my EOF classes may be > executed by more than one thread at a time. I use lazy initialisation > but there is a race condition there. Fortunately, most of the time > there are no side-effects and running that code twice would have no > significant deleterious effect. For situations where it would matter I > would assume protecting lazy initialisation with a double check and a > synchronised block for the inner check would be fine? Is that > interpretation correct? I think that synchronised is what you want. > Are there other commandments? Don't Do Stupid Things :-) Which boils down to don't share objects that are not thread-safe, or writable data, at the global level unless you have appropriate protection. Global being either static members or instance variables on your application. Shared, non-thread safe formatters are a common mistake. Chuck -- Chuck Hill Senior Consultant / VP Development 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 smime.p7s Description: S/MIME cryptographic signature ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Concurrent request handling
>> Hello all ! >> I am wondering whether to turn on concurrent request handling on my >> deployment or not. > > I always have this on. > >> What are potential drawbacks of this? I assume there should be some. >> Why would it be off by default otherwise? >> I could not find anything interesting on this in documentation. > > WebObjects has several defaults that are not what most people would want. I > think these defaults were set to preserve existing behavior when new features > were added. Unless you are sharing unlocked global writable data (from > static ivars or Application), there is no reason to NOT have this on. If you > are sharing unlocked global writable data, then you are Bad Person and should > fix this! > Thank you for explanation. I think, I'll turn it on then. I hope I'm not that bad :-) >> And another question: would concurrent request handling save me from >> global application deadlocks when one single request locks on >> exception? > > > Maybe. It depends on why that session/request is deadlocking. I would focus > on fixing that. > There is a theorem that every code has at least one error. And consequently it has unlimited number of errors. My code is several tens thousand rows written on different stages of my understanding of WebObjects Tao. Deadlock happen after some errors as ECs don't get unlocked after those unexpected throwings. Especially after "Out of memory error" that can not be captured. Gennady ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Concurrent request handling
On Mar 10, 2011, at 1:22 AM, Gennady Kushnir wrote: > Hello all ! > I am wondering whether to turn on concurrent request handling on my > deployment or not. I always have this on. > What are potential drawbacks of this? I assume there should be some. > Why would it be off by default otherwise? > I could not find anything interesting on this in documentation. WebObjects has several defaults that are not what most people would want. I think these defaults were set to preserve existing behavior when new features were added. Unless you are sharing unlocked global writable data (from static ivars or Application), there is no reason to NOT have this on. If you are sharing unlocked global writable data, then you are Bad Person and should fix this! > And another question: would concurrent request handling save me from > global application deadlocks when one single request locks on > exception? Maybe. It depends on why that session/request is deadlocking. I would focus on fixing that. Chuck -- Chuck Hill Senior Consultant / VP Development 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 smime.p7s Description: S/MIME cryptographic signature ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Concurrent request handling
Hello Gennady; If you are having application-freezes on exceptions that may be another problem and it may be best to conclusively sort that out rather than work around it. cheers. On 10/03/11 10:22 PM, Gennady Kushnir wrote: Hello all ! I am wondering whether to turn on concurrent request handling on my deployment or not. What are potential drawbacks of this? I assume there should be some. Why would it be off by default otherwise? I could not find anything interesting on this in documentation. And another question: would concurrent request handling save me from global application deadlocks when one single request locks on exception? -- Andrew Lindesay www.silvereye.co.nz ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
