X-CGP-ClamAV-Result: CLEAN X-VirusScanner: Niversoft's CGPClamav Helper v1.22.2a (ClamAV engine v0.102.2) X-Junk-Score: 0 [] X-KAS-Score: 0 [] From: "Samuel Pelletier" Received: from fortimail.cybercat.ca ([216.13.210.77] verified) by post.selbstdenker.com (CommuniGate Pro SMTP 6.3.3) with ESMTPS id 25390233 for webobjects-dev@wocommunity.org; Wed, 10 Feb 2021 14:16:35 +0100 Received-SPF: none receiver=post.selbstdenker.com; client-ip=216.13.210.77; envelope-from=samuel@samkar.com Received: from [10.70.4.100] (modemcable070.93-179-173.mc.videotron.ca [173.179.93.70]) (user=samuel%samkar.com mech=PLAIN bits=0) by fortimail.cybercat.ca with ESMTP id 11ADGCjv006215-11ADGCjw006215 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 10 Feb 2021 08:16:12 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_E04008E5-42C6-408A-BFE3-0F771E831A7B" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: Re: [WO-DEV] Urgent Out of Memory help needed Date: Wed, 10 Feb 2021 08:16:11 -0500 References: To: WebObjects & WOnder Development In-Reply-To: Message-Id: <4FBF374D-2CD9-4606-B418-7D84AE2F5372@samkar.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-FEAS-AUTH-USER: samuel%samkar.com --Apple-Mail=_E04008E5-42C6-408A-BFE3-0F771E831A7B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Markus, I would add a detailed log on session creation (in the constructor for = example) with the complete request URL, source and referrer. This way, = your should be able to identify the source of the problem, either a web = crawler, problem in Ajax call or a loop in error handling that create = many sessions when some error occur. I had some case of error handling = that looped in redirects until the browser decided to stop the loop. To reduce the impact of false session creation, I usually create session = with an initial timeout of 2-4 minutes until the user is properly = authenticated and adjust it there to 20-60 minutes. Even there, I now = often add Ajax ping to keep the session alive and reduce their timeout = on the server so the number seems on the server is more representative = of the reality. Regards, Samuel > Le 8 f=C3=A9vr. 2021 =C3=A0 03:42, Markus Ruggiero (rucotec) = a =C3=A9crit : >=20 > We are running the same application code in a handful of instances. = Each instance is dedicated to one customer. There are only some very = small differences between the instances like db credentials and some = webserver resources (customer specific logo etc). One customer is = driving their dedicated instance regularly into java memory exhaustion, = all others have no problem. This particular customer is using one screen = more than other customers do. This screen has a couple Ajax components, = but as far as I can tell nothing too fancy. In WOMonitor we can see that = the Running Session count at the bottom right of the details display = goes up like crazy. Within hours the count can reach 1500+. I started to = trace all Session creation (Thread.dumpStack() in Session constructor) = but as expected there was exactly one session being created at login, = then none more.=20 >=20 > What the heck is going on here? What does WOMonitor display here? = Obviously must be something other than just session creation. Could this = be an Ajax issue? Where would you start? We upped the JVM memory to 2G = to survive the day and have more instances for that particular customer = running. >=20 > Btw: how do you go into WOStatistics? Setting a statistics password in = WOMonitor did not help, the direct action always comes back with a = browser error (Safari can=E2=80=99t open the page bla bla bla). I seem = the miss something here. >=20 > Thanks for any help > ---markus--- >=20 > Markus Ruggiero >=20 > rucotec GmbH web https://rucotec.ch = > Steinenvorstadt 79 email markus.ruggiero@rucotec.ch = > 4051 Basel / Switzerland mobile +41 79 508 4701 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_E04008E5-42C6-408A-BFE3-0F771E831A7B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Markus,

I would add = a detailed log on session creation (in the constructor for example) with = the complete request URL, source and referrer. This way, your should be = able to identify the source of the problem, either a web crawler, = problem in Ajax call or a loop in error handling that create many = sessions when some error occur. I had some case of error handling that = looped in redirects until the browser decided to stop the = loop.

To = reduce the impact of false session creation, I usually create session = with an initial timeout of 2-4 minutes until the user is properly = authenticated and adjust it there to 20-60 minutes. Even there, I now = often add Ajax ping to keep the session alive and reduce their timeout = on the server so the number seems on the server is more representative = of the reality.

Regards,

Samuel


Le 8 = f=C3=A9vr. 2021 =C3=A0 03:42, Markus Ruggiero (rucotec) <webobjects-dev@wocommunity.org> a =C3=A9crit = :

We are running the = same application code in a handful of instances. Each instance is = dedicated to one customer. There are only some very small differences = between the instances like db credentials and some webserver resources = (customer specific logo etc). One customer is driving their dedicated = instance regularly into java memory exhaustion, all others have no = problem. This particular customer is using one screen more than other = customers do. This screen has a couple Ajax components, but as far as I = can tell nothing too fancy. In WOMonitor we can see that the Running = Session count at the bottom right of the details display goes up like = crazy. Within hours the count can reach 1500+. I started to trace all = Session creation (Thread.dumpStack() in Session constructor) but as = expected there was exactly one session being created at login, then none = more. 

What the = heck is going on here? What does WOMonitor display here? Obviously must = be something other than just session creation. Could this be an Ajax = issue? Where would you start? We upped the JVM memory to 2G to survive = the day and have more instances for that particular customer = running.

Btw: = how do you go into WOStatistics? Setting a statistics password in = WOMonitor did not help, the direct action always comes back with a = browser error (Safari can=E2=80=99t open the page bla bla bla). I seem = the miss something here.

Thanks for any help
---markus---

Markus = Ruggiero

rucotec GmbH              =           web https://rucotec.ch
Steinenvorstadt 79          =       email markus.ruggiero@rucotec.ch
4051 Basel / = Switzerland         mobile +41 79 508 4701









= --Apple-Mail=_E04008E5-42C6-408A-BFE3-0F771E831A7B--