log4j Settings For iPhone
I have log4j shooting out emails on errors which is great, but does anyone have any settings that make it sane to read on my iphone? When I get errors sometimes I'm getting HUGE dumps that take me at least 30 seconds to scroll to the bottom, then when I do the formatting is so illegible I can barely decipher what the the issue is. Any suggestions? ___ 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: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Immortal sessions in production
Thanks, I'll try that.
Anyway (I can't say it's that but this happens often in instances with
immortal sessions):
I get this in my terminate() method
java.lang.IllegalMonitorStateException
at
java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:127)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1239)
at
java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:431)
at
com.webobjects.eocontrol.EOObjectStoreCoordinator.unlock(EOObjectStoreCoordinator.java:460)
at
com.webobjects.eocontrol.EOEditingContext.unlockObjectStore(EOEditingContext.java:4684)
at er.extensions.eof.ERXEC.unlockObjectStore(ERXEC.java:805)
at
com.webobjects.eocontrol.EOCustomObject.willReadRelationship(EOCustomObject.java:1281)
at
er.extensions.eof.ERXGenericRecord.willReadRelationship(ERXGenericRecord.java:378)
at
com.webobjects.eocontrol._EOMutableKnownKeyDictionary$Initializer$_LazyGenericRecordBinding.valueInObject(_EOMutableKnownKeyDictionary.java:614)
at
com.webobjects.eocontrol.EOCustomObject.storedValueForKey(EOCustomObject.java:1634)
I'm using ERXEC everywhere and I'm not locking explicitly, should I
lock the ec in the terminate method?
Matteo
On Sat, Jan 12, 2013 at 8:39 PM, Simon wrote:
> stick this in your session constructor, it will log out whenever a
> session is created. then you can start figuring out where you are
> creating a session outside the RR loop which is the normal culprit...
>
> StringWriter stringWriter = new StringWriter();
> PrintWriter printWriter = new
> PrintWriter(stringWriter);
> (new Throwable()).printStackTrace(printWriter);
> String trace = stringWriter.toString();
> log.debug("Session count = " +
> application().activeSessionsCount());
>
> ClickEventLogger2.getLogger().fatal(ClickEventCode.E00129, "Session
> Created:\n\n " + trace,
> this.getClass().getSimpleName());
>
> hmmm, you'll have to replace the "ClickEventLogger2" line because
> that's our logging mechanism. you could log.fatal it and set up an
> email appender in log4j.
>
> simon
>
>
> On 12 January 2013 17:43, Matteo Centro wrote:
>> Sorry to resuscitate such an old discussion but I'm having the exact
>> same issue...
>> It's an old application that we "inherited", we wonderized it as much
>> as it's possible but something weird happens in production, sessions
>> on some instances simply won't die.
>> Some instances go out of memory and they hang there.
>> I'm in trouble and I needs some hints, both to fix the issue
>> temporarily and to fix it for good (of course in that case I assume
>> I'll have to rewrite the app, if only I could find the budget).
>> What are the most common causes of sessions not dying?
>>
>> Thanks,
>>
>>
>> Matteo
>>
>> On Thu, Aug 21, 2008 at 5:35 AM, Joe Little wrote:
>>> I had something similar with sessions going bonkers on a public WO
>>> page that our internal google search engine completely trashed. In the
>>> end, robots.txt and explicit rules to deny certain patterns were added
>>> to prevent this.
>>>
>>>
>>> On Wed, Aug 20, 2008 at 8:17 PM, D Tim Cummings wrote:
We have a couple of sessionless apps that have started showing this problem
with sessions that don't terminate. It turned out the sessions were being
created by malformed urls coming from malicious robot web crawlers. The
urls were of the form
http://www.courses.qut.edu.au/cgi-bin/WebObjects/Courses.woa/wa/cgi-bin/WebObjects/Courses.woa
Maybe see if you are getting incorrect links to your sessionless login
page.
We solved the problem by catching unknown direct actions in
DirectAction.java
@Override
public WOActionResults performActionNamed(String actionName) {
try {
return super.performActionNamed(actionName);
} catch (NSForwardException nsfe) {
log.info("ns forward exception - prbalby no such method for " +
actionName);
}
return defaultAction();
}
and in Application.java directing exceptions back to the Main page (for
URLs
with more than one / after wa).
@Override
public WOComponent pageWithName(String namePage, WOContext context) {
if ( "WOExceptionPage".equals(namePage) ) {
namePage = "Main";
}
if ( "WOSessionRestorationError".equals(namePage) ) {
namePage = "Main";
}
return super.pageWithName(namePage, context);
}
and in Main.java
public void setException ( Exception e ) {
log.error("an exception occurred " + e);
}
We are running apps with embedded Wonder 4 and WebObjects 5.3.3 on Mac OS X
Server 10.5.4 with WebObjects 5.4.2 deployment. We didn't have the problem
before we we
Re: Immortal sessions in production
stick this in your session constructor, it will log out whenever a
session is created. then you can start figuring out where you are
creating a session outside the RR loop which is the normal culprit...
StringWriter stringWriter = new StringWriter();
PrintWriter printWriter = new PrintWriter(stringWriter);
(new Throwable()).printStackTrace(printWriter);
String trace = stringWriter.toString();
log.debug("Session count = " +
application().activeSessionsCount());
ClickEventLogger2.getLogger().fatal(ClickEventCode.E00129, "Session
Created:\n\n " + trace,
this.getClass().getSimpleName());
hmmm, you'll have to replace the "ClickEventLogger2" line because
that's our logging mechanism. you could log.fatal it and set up an
email appender in log4j.
simon
On 12 January 2013 17:43, Matteo Centro wrote:
> Sorry to resuscitate such an old discussion but I'm having the exact
> same issue...
> It's an old application that we "inherited", we wonderized it as much
> as it's possible but something weird happens in production, sessions
> on some instances simply won't die.
> Some instances go out of memory and they hang there.
> I'm in trouble and I needs some hints, both to fix the issue
> temporarily and to fix it for good (of course in that case I assume
> I'll have to rewrite the app, if only I could find the budget).
> What are the most common causes of sessions not dying?
>
> Thanks,
>
>
> Matteo
>
> On Thu, Aug 21, 2008 at 5:35 AM, Joe Little wrote:
>> I had something similar with sessions going bonkers on a public WO
>> page that our internal google search engine completely trashed. In the
>> end, robots.txt and explicit rules to deny certain patterns were added
>> to prevent this.
>>
>>
>> On Wed, Aug 20, 2008 at 8:17 PM, D Tim Cummings wrote:
>>> We have a couple of sessionless apps that have started showing this problem
>>> with sessions that don't terminate. It turned out the sessions were being
>>> created by malformed urls coming from malicious robot web crawlers. The
>>> urls were of the form
>>> http://www.courses.qut.edu.au/cgi-bin/WebObjects/Courses.woa/wa/cgi-bin/WebObjects/Courses.woa
>>> Maybe see if you are getting incorrect links to your sessionless login page.
>>> We solved the problem by catching unknown direct actions in
>>> DirectAction.java
>>> @Override
>>> public WOActionResults performActionNamed(String actionName) {
>>> try {
>>> return super.performActionNamed(actionName);
>>> } catch (NSForwardException nsfe) {
>>> log.info("ns forward exception - prbalby no such method for " + actionName);
>>> }
>>> return defaultAction();
>>> }
>>> and in Application.java directing exceptions back to the Main page (for URLs
>>> with more than one / after wa).
>>> @Override
>>> public WOComponent pageWithName(String namePage, WOContext context) {
>>> if ( "WOExceptionPage".equals(namePage) ) {
>>> namePage = "Main";
>>> }
>>> if ( "WOSessionRestorationError".equals(namePage) ) {
>>> namePage = "Main";
>>> }
>>> return super.pageWithName(namePage, context);
>>> }
>>>
>>> and in Main.java
>>> public void setException ( Exception e ) {
>>> log.error("an exception occurred " + e);
>>> }
>>>
>>> We are running apps with embedded Wonder 4 and WebObjects 5.3.3 on Mac OS X
>>> Server 10.5.4 with WebObjects 5.4.2 deployment. We didn't have the problem
>>> before we went to this setup, but maybe we weren't getting hit with the same
>>> url format then.
>>> Tim
>>> On 21/08/2008, at 4:02 AM, Chuck Hill wrote:
>>>
>>> On Aug 20, 2008, at 9:54 AM, Simon McLean wrote:
>>>
>>> Hi All -
>>> Wondering if someone can throw me some ideas on solving what looks like an
>>> immortal session problem.
>>> - Start up 1 instance in java monitor.
>>> - User lands on sessionless login page. No sessions.
>>> - User logs in. 1 session.
>>> - User logs out. 0 sessions.
>>> - User logs in. 1 session.
>>> - User does nothing. Session times out. 0 sessions.
>>> All looks good. However, we get to the end of the day and the instance has
>>> 376 active sessions. But I know for this particular app there are only 6
>>> users, because they are all sitting next door :-) Also, If i now leave this
>>> instance overnight none of those active sessions will go away.
>>> So what could be going on ? Something appears to be creating immortal
>>> sessions, but forced session termination (by the user logging out) and
>>> session expiration seem to be behaving themselves.
>>>
>>> If the users don't notice any problems, my money would be on an exception
>>> thrown from your Session.terminate(). Also check the sleep() method to
>>> ensure it can never throw.
>>> I have seen a related problem where two requests come in for the same
>>> session (user double clicks, Ajax etc), and the first calls terminate() on
>>> the session. The second thread is stuck and the app ca
Re: Immortal sessions in production
have you done tests like sending a backtrace to the session just to see if it
is hung somewhere?
I recall finding sessions getting stuck on a poorly written ec threading issue
that only came up once in a blue moon it seemed.
once I saw a backtrace, it was quite obvious where the trouble was.
On Jan 12, 2013, at 12:43 PM, Matteo Centro wrote:
> Sorry to resuscitate such an old discussion but I'm having the exact
> same issue...
> It's an old application that we "inherited", we wonderized it as much
> as it's possible but something weird happens in production, sessions
> on some instances simply won't die.
> Some instances go out of memory and they hang there.
> I'm in trouble and I needs some hints, both to fix the issue
> temporarily and to fix it for good (of course in that case I assume
> I'll have to rewrite the app, if only I could find the budget).
> What are the most common causes of sessions not dying?
>
> Thanks,
>
>
> Matteo
>
> On Thu, Aug 21, 2008 at 5:35 AM, Joe Little wrote:
>> I had something similar with sessions going bonkers on a public WO
>> page that our internal google search engine completely trashed. In the
>> end, robots.txt and explicit rules to deny certain patterns were added
>> to prevent this.
>>
>>
>> On Wed, Aug 20, 2008 at 8:17 PM, D Tim Cummings wrote:
>>> We have a couple of sessionless apps that have started showing this problem
>>> with sessions that don't terminate. It turned out the sessions were being
>>> created by malformed urls coming from malicious robot web crawlers. The
>>> urls were of the form
>>> http://www.courses.qut.edu.au/cgi-bin/WebObjects/Courses.woa/wa/cgi-bin/WebObjects/Courses.woa
>>> Maybe see if you are getting incorrect links to your sessionless login page.
>>> We solved the problem by catching unknown direct actions in
>>> DirectAction.java
>>> @Override
>>> public WOActionResults performActionNamed(String actionName) {
>>> try {
>>> return super.performActionNamed(actionName);
>>> } catch (NSForwardException nsfe) {
>>> log.info("ns forward exception - prbalby no such method for " + actionName);
>>> }
>>> return defaultAction();
>>> }
>>> and in Application.java directing exceptions back to the Main page (for URLs
>>> with more than one / after wa).
>>> @Override
>>> public WOComponent pageWithName(String namePage, WOContext context) {
>>> if ( "WOExceptionPage".equals(namePage) ) {
>>> namePage = "Main";
>>> }
>>> if ( "WOSessionRestorationError".equals(namePage) ) {
>>> namePage = "Main";
>>> }
>>> return super.pageWithName(namePage, context);
>>> }
>>>
>>> and in Main.java
>>> public void setException ( Exception e ) {
>>> log.error("an exception occurred " + e);
>>> }
>>>
>>> We are running apps with embedded Wonder 4 and WebObjects 5.3.3 on Mac OS X
>>> Server 10.5.4 with WebObjects 5.4.2 deployment. We didn't have the problem
>>> before we went to this setup, but maybe we weren't getting hit with the same
>>> url format then.
>>> Tim
>>> On 21/08/2008, at 4:02 AM, Chuck Hill wrote:
>>>
>>> On Aug 20, 2008, at 9:54 AM, Simon McLean wrote:
>>>
>>> Hi All -
>>> Wondering if someone can throw me some ideas on solving what looks like an
>>> immortal session problem.
>>> - Start up 1 instance in java monitor.
>>> - User lands on sessionless login page. No sessions.
>>> - User logs in. 1 session.
>>> - User logs out. 0 sessions.
>>> - User logs in. 1 session.
>>> - User does nothing. Session times out. 0 sessions.
>>> All looks good. However, we get to the end of the day and the instance has
>>> 376 active sessions. But I know for this particular app there are only 6
>>> users, because they are all sitting next door :-) Also, If i now leave this
>>> instance overnight none of those active sessions will go away.
>>> So what could be going on ? Something appears to be creating immortal
>>> sessions, but forced session termination (by the user logging out) and
>>> session expiration seem to be behaving themselves.
>>>
>>> If the users don't notice any problems, my money would be on an exception
>>> thrown from your Session.terminate(). Also check the sleep() method to
>>> ensure it can never throw.
>>> I have seen a related problem where two requests come in for the same
>>> session (user double clicks, Ajax etc), and the first calls terminate() on
>>> the session. The second thread is stuck and the app can't gracefully shut
>>> down. IIRC, you would see zero sessions in this case. The "fix" for this
>>> is to not call terminate() and instead set the session timeout to a small
>>> number of seconds.
>>> 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 ig
installing AWS S3 command line tools?
Anyone know what I need to install here? I'm setting up a Mac OSX developer box and wanted to push my ant build onto AWS S3 when I ran into this error: Can't locate Net/Amazon/S3.pm in @INC I see this page refers to the command line tools: http://wiki.wocommunity.org/display/documentation/Deploying+on+Amazon+EC2 which brings me to this page: http://timkay.com/aws/ but all I see is windows installation? am I on the wrong track here? ___ 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: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Immortal sessions in production
Sorry to resuscitate such an old discussion but I'm having the exact
same issue...
It's an old application that we "inherited", we wonderized it as much
as it's possible but something weird happens in production, sessions
on some instances simply won't die.
Some instances go out of memory and they hang there.
I'm in trouble and I needs some hints, both to fix the issue
temporarily and to fix it for good (of course in that case I assume
I'll have to rewrite the app, if only I could find the budget).
What are the most common causes of sessions not dying?
Thanks,
Matteo
On Thu, Aug 21, 2008 at 5:35 AM, Joe Little wrote:
> I had something similar with sessions going bonkers on a public WO
> page that our internal google search engine completely trashed. In the
> end, robots.txt and explicit rules to deny certain patterns were added
> to prevent this.
>
>
> On Wed, Aug 20, 2008 at 8:17 PM, D Tim Cummings wrote:
>> We have a couple of sessionless apps that have started showing this problem
>> with sessions that don't terminate. It turned out the sessions were being
>> created by malformed urls coming from malicious robot web crawlers. The
>> urls were of the form
>> http://www.courses.qut.edu.au/cgi-bin/WebObjects/Courses.woa/wa/cgi-bin/WebObjects/Courses.woa
>> Maybe see if you are getting incorrect links to your sessionless login page.
>> We solved the problem by catching unknown direct actions in
>> DirectAction.java
>> @Override
>> public WOActionResults performActionNamed(String actionName) {
>> try {
>> return super.performActionNamed(actionName);
>> } catch (NSForwardException nsfe) {
>> log.info("ns forward exception - prbalby no such method for " + actionName);
>> }
>> return defaultAction();
>> }
>> and in Application.java directing exceptions back to the Main page (for URLs
>> with more than one / after wa).
>> @Override
>> public WOComponent pageWithName(String namePage, WOContext context) {
>> if ( "WOExceptionPage".equals(namePage) ) {
>> namePage = "Main";
>> }
>> if ( "WOSessionRestorationError".equals(namePage) ) {
>> namePage = "Main";
>> }
>> return super.pageWithName(namePage, context);
>> }
>>
>> and in Main.java
>> public void setException ( Exception e ) {
>> log.error("an exception occurred " + e);
>> }
>>
>> We are running apps with embedded Wonder 4 and WebObjects 5.3.3 on Mac OS X
>> Server 10.5.4 with WebObjects 5.4.2 deployment. We didn't have the problem
>> before we went to this setup, but maybe we weren't getting hit with the same
>> url format then.
>> Tim
>> On 21/08/2008, at 4:02 AM, Chuck Hill wrote:
>>
>> On Aug 20, 2008, at 9:54 AM, Simon McLean wrote:
>>
>> Hi All -
>> Wondering if someone can throw me some ideas on solving what looks like an
>> immortal session problem.
>> - Start up 1 instance in java monitor.
>> - User lands on sessionless login page. No sessions.
>> - User logs in. 1 session.
>> - User logs out. 0 sessions.
>> - User logs in. 1 session.
>> - User does nothing. Session times out. 0 sessions.
>> All looks good. However, we get to the end of the day and the instance has
>> 376 active sessions. But I know for this particular app there are only 6
>> users, because they are all sitting next door :-) Also, If i now leave this
>> instance overnight none of those active sessions will go away.
>> So what could be going on ? Something appears to be creating immortal
>> sessions, but forced session termination (by the user logging out) and
>> session expiration seem to be behaving themselves.
>>
>> If the users don't notice any problems, my money would be on an exception
>> thrown from your Session.terminate(). Also check the sleep() method to
>> ensure it can never throw.
>> I have seen a related problem where two requests come in for the same
>> session (user double clicks, Ajax etc), and the first calls terminate() on
>> the session. The second thread is stuck and the app can't gracefully shut
>> down. IIRC, you would see zero sessions in this case. The "fix" for this
>> is to not call terminate() and instead set the session timeout to a small
>> number of seconds.
>> 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/timcu%40tpg.com.au
>> This email sent to ti...@tpg.com.au
>>
>>
>>
>> ___
>> 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://l
Re: Wonder 6.0.0 is out in the wild!
Hi, sure! Where is the place for these kind of binaries? Regards, Markus Am 11.01.2013 um 17:34 schrieb Stéphan Mertz : > Hello Markus, > > Could you provide to the community a 32 and 64bits of the tool ? > > Thank you very much, > > Stéphan > > Le 9 janv. 2013 à 22:04, Markus Stoll a écrit : > >>> Nice job ! >>> For WOStart : >>> . How to use it? >>> . Can it be used with wotaskd ? >> >> The WOStart can be used instead of the .cmd script under Windows >> Just copy it into your .woa folder and name it .exe >> and use it exactly like the cmd script. >> >> I never tested this with wotaskd, but I see no reason, why it shouldn't >> work. >> >> Markus >> >> ___ >> 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: >> https://lists.apple.com/mailman/options/webobjects-dev/s.mertz%40improve.fr >> >> This email sent to s.me...@improve.fr > -- Dr. Markus Stoll (Geschäftsführer) markus.st...@junidas.de junidas GmbH, Aixheimer Str. 12, 70619 Stuttgart Tel. +49 (711) 4599799-11, Fax +49 (711) 4599799-10 Geschäftsführer: Dr. Markus Stoll, Matthias Zepf Amtsgericht Stuttgart, HRB 21939 ___ 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: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
