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: "OCsite" Received: from smtp-beta-1.zoner.com ([217.198.120.69] verified) by post.selbstdenker.com (CommuniGate Pro SMTP 6.3.3) with ESMTPS id 25376755 for webobjects-dev@wocommunity.org; Mon, 08 Feb 2021 14:35:26 +0100 Received-SPF: none receiver=post.selbstdenker.com; client-ip=217.198.120.69; envelope-from=ocs@ocs.cz Received: from smtp.zoner.com (smtp.zoner.com [217.198.120.6]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp-beta-1.zoner.com (Postfix) with ESMTPS id 9627218010CE for ; Mon, 8 Feb 2021 14:35:05 +0100 (CET) Received: from macbook-pro.ocsluj (smtp2stechovice.cli-eurosignal.cz [77.240.99.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: ocs@ocs.cz) by smtp.zoner.com (Postfix) with ESMTPSA id 4946B30000C3 for ; Mon, 8 Feb 2021 14:35:05 +0100 (CET) Content-Type: multipart/alternative; boundary="Apple-Mail=_08B7CE70-025E-4B59-949F-5214442EA77A" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: [WO-DEV] Urgent Out of Memory help needed Date: Mon, 8 Feb 2021 14:35:04 +0100 References: To: WebObjects & WOnder Development In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) --Apple-Mail=_08B7CE70-025E-4B59-949F-5214442EA77A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Markus, you might want to check the Apache/adaptor logs for the bloody Google = bot: unless switched off by proper robots.txt, the darned thing tends to = try URLs containing stale session IDs all the time, creating so = thousands of sessions and running apps outta memory fast. We bumped into = this very problem a couple of times. Would be much better if Google made = their crawler strictly opt-in, but hell, it's Google =E2=80=94 we can = consider ourselves lucky they have at least the basic decency to check = robots.txt :( All the best, OC > On 8 Feb 2021, at 9:42, Markus Ruggiero (rucotec) = wrote: >=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=_08B7CE70-025E-4B59-949F-5214442EA77A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Markus,

you= might want to check the Apache/adaptor logs for the bloody Google bot: = unless switched off by proper robots.txt, the darned thing tends to try = URLs containing stale session IDs all the time, creating so thousands of = sessions and running apps outta memory fast. We bumped into this very = problem a couple of times. Would be much better if Google made their = crawler strictly opt-in, but hell, it's Google =E2=80=94 we can consider = ourselves lucky they have at least the basic decency to check robots.txt = :(

All the = best,
OC

On 8 Feb = 2021, at 9:42, Markus Ruggiero (rucotec) <webobjects-dev@wocommunity.org> wrote:

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=_08B7CE70-025E-4B59-949F-5214442EA77A--