Hello again, Rob, Thanks for your reply. This is admittedly beyond my level of expertise, but I'm learning.
A little context. My website is www.worldholidaysandevents.com. This has two components: (1) a backend webservice running Glassfish and MySql, and (2) a website that serves as a user interface that consumes the webservice and which was recently created using Next.js. The new website was written by a former student that I can still consult with as needed, but otherwise the "team" is just me. The student was very knowledgeable, having done this same kind of work in India before coming to my university. He set this up with an nginx front end, and I can see the accesses in the nginx access.log file. This file is too large for email, but you can view it at www.cs.fsu.edu/~schwartz/access.log. This contains all accesses since Monday, 8/4. The lines that make a reference to "calendar" and some combination of "country", "state", "city", "year" are all database requests. The IP address 73.118.50.199 is me, running tests. Many of the others are created by web crawlers, with names like Googlebot, DotBot, PetalBot, SemrushBot, bingbot, etc. However, many of the entries also don't seem to be from webcrawlers, but appear to be bogus requests. For example, the following line occurs repeatedly: 96.9.89.82 - - [04/Aug/2025:22:49:12 +0000] "GET /_next/static/css/a2a6f669bb486c52.css HTTP/1.1" 200 6473 "https://www.worldholidaysandevents.com/calendar?country=Cambodia&year=1983"; "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36" And there are other similar types of requests that seem to be manufactured by some robot and that are not identified as coming from a webcrawler (or at least no webcrawler name is given). My student says that the webcrawlers serve a useful purpose in helping with SEO, so they are a necessary evil. But the others I believe should be blocked, and I understand that this can be done by listing the IP addresses somewhere in nginx. I'm trying figure out how to do this. Let me also mention that I recently talked with a person at a company called Omnifish, based in Prague I think, that specializes in consulting for Glassfish. He said that the total number of concurrent connections is limited by the maximum size of the pool. Accordingly, getting an error message saying that no additional connections can be created, and the system crashing, occurs when all the connections in the pool are currently in use. He considered this to be normal behavior. That's why I set the size to 1000. It seems to be working. However, if I were designing a pooling system, I wouldn't do it this way, and it seems that other pooling systems do allow for additional connections outside the pool. Anyway, any further insights you or anyone can give will be appreciated. Dan Schwartz From: Rob Sargent <rsarg...@xmission.com> Sent: Tuesday, August 5, 2025 11:40 PM To: Tomcat Users List <users@tomcat.apache.org> Cc: Tomcat Users List <users@tomcat.apache.org> Subject: Re: How to access a REST service > On Aug 5, 2025, at 11:54 AM, Daniel Schwartz > <d...@danielgschwartz.com<mailto:d...@danielgschwartz.com>> wrote: > > Hello > again Rob, > > I just read that article you referenced by Cockroach Labs. I > found the statement: > > "If we make the NkdkJdXPPEBannerStart Be Careful With This Message From (Rob Sargent <rsarg...@xmission.com>)<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f1933ea4495d1e4e6e586f0daa8cc6fc871f8631d90342b3e3b73ecb5c6821f786c62f34375bd457a77a4668c15a9446ce1bc5132cf77cbf0be1808f5ebde108808a9a78dcfd981c6b6676df0a8d4944f8b685e15e03ad23ccc798ffdc9c0341efc607b18a96bf37ec3de055760a4984a04f4e70bcbd9fe5e5bc5f1cee0293f413ed97673720d5a9c3d52f1de8787f821f6f776e586b31e3afd1d2c6ea875591c4de3f4928fe99a35f78a1ba82c74b95c02e67da46fe368ef5c1fe726f0c54de0a8d360ef3c80b54db3657b681de4e15544d0a1a88908fa8d27b97335b585492acb5cb53586e3f107> Learn More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f1933ea4495d1e4e6e586f0daa8cc6fc871f8631d90342b3e3b73ecb5c6821f786c62f34375bd457a77a4668c15a9446ce1bc5132cf77cbf0be1808f5ebde108808a9a78dcfd981c6b6676df0a8d4944f8b685e15e03ad23ccc798ffdc9c0341efc607b18a96bf37ec3de055760a4984a04f4e70bcbd9fe5e5bc5f1cee0293f413ed97673720d5a9c3d52f1de8787f821f6f776e586b31e3afd1d2c6ea875591c4de3f4928fe99a35f78a1ba82c74b95c02e67da46fe368ef5c1fe726f0c54de0a8d360ef3c80b54db3657b681de4e15544d0a1a88908fa8d27b97335b585492acb5cb53586e3f107> Potential Impersonation The sender's identity could not be verified and someone may be impersonating the sender. Take caution when interacting with this message. NkdkJdXPPEBannerEnd > On Aug 5, 2025, at 11:54 AM, Daniel Schwartz > <d...@danielgschwartz.com<mailto:d...@danielgschwartz.com>> wrote: > > Hello again Rob, > > I just read that article you referenced by Cockroach Labs. I found the > statement: > > "If we make the pool too small (i.e. choose too few connections), we’ll > introduce latency, as operations have to wait for an available connection to > open up before they can execute." > > This implies that if the number of concurrent accesses exceeds the number of > connection objects in the pool, then the system simply waits until some of > the currently active connections terminate and the connection objects become > available. > > This is not what was happening with Glassfish. When the number of > simultaneous requests exceeds the pool size, the system outputs an error > message and crashes. It doesn't just wait until some active connections > terminate so that the connection objects become available. It seems that > different pooling systems have different policies. > Bottom posting is generally preferred. Crop to appropriate portion of original. Are web crawlers making database requests? Do you know which db calls are actually being made? And when? Is the switch from 32 to 1000 the only change you made? I don’t think I am the only one here who thinks that is a red herring. You may need to give more information: db server, connection configuration, servlet code, logs (app, middle tier, dbserver). I suspect you may have been compromised. Is there anyone at your sight who can comment on this? --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org<mailto:users-unsubscr...@tomcat.apache.org> For additional commands, e-mail: users-h...@tomcat.apache.org<mailto:users-h...@tomcat.apache.org>
