× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



IF your jdbc application or connection is a single, unique, userid, you
could try to get some arms around work management this with "Subsystem
Routing by User". We force each individual application to have a specific
userid, it gives us a greater ability to control and debug.

We were being abused years ago by similar and connection pooling is
controlled by the Client... for better or worse.

https://www.ibm.com/support/pages/routing-connections-subsystems-based-user-id




On Mon, Dec 29, 2025 at 1:55 PM Richard Schoen <richard@xxxxxxxxxxxxxxxxx>
wrote:

This seems a whole lot of messed up.

Why can’t they just self-limit their process since they plan to put logic
in to look for a 6th connect attempt to fail ?

It does sound like a combination of exit point logic and some SQL Services
might be able to see how many connections open from an IP address if they
really CANT limit trying to open too many connections.

Feels like super-sloppy DB coding to me. Why not just fix their app since
it sounds like they plan to code to accommodate the 6th connect failure ?

Anyway:
In your exit point you would probably have to use something like an SQL
Service to see how many connections from that IP address on the DB port.
When could exceeds 5, kick it out.

I don’t know of any good example but Fortra, Kisco and others have
commercial products you can plug in quickly.

Regards,
Richard Schoen
Web: http://www.richardschoen.net
Email: richard@xxxxxxxxxxxxxxxxx


----------------------------------------------------------------------

message: 1
date: Sun, 28 Dec 2025 16:59:31 -0500
from: smith5646midrange@xxxxxxxxx
subject: Blocking excessive JDBC connections

My client has a problem where non-IBMi applications (Windows servers) are
creating MANY JDBC connections to pull data.one file is 98G and is pulled
in
full every day. Their app needs to finish faster so they create additional
threads to bust up the file but they never talk to us about it first. Our
system currently sits at over 100% CPU for hours at a time while these JDBC
connections are active. Last night it was 4+ hours at 150+%. This is
impacting other IBMi programs.



There is a whole lot wrong with that previous paragraph and we are actively
working on the root of the problem but it is a long process getting it
changed. I don't need help fixing that part of the problem so please don't
offer solutions for it.



The problem that I am trying to solve is how to limit the number of JDBC
connections from a single IP address. They are connecting through a job
named QRWTSVR (or something close to that). When I look at the joblog, I
can see what IP address did the connection. I have gotten permission to
limit an IP address to 5 threads and if they try to open a sixth, it will
fail. This sixth connection's failure assumes all of the first five jobs
are still active. If one has ended / disconnected, the sixth connection
should be allowed. My problem is how can I do it? Is there a way through
an exit point? I've been looking but not finding anything. The exit
points
that I have found do not show me the job information.



Does anybody have any thoughts that I can research to find a way do to
this?


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2026 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.