Re: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem?

[Rob Sargent]

> On Dec 30, 2021, at 4:33 PM, Eric Robinson  wrote:
> 
> Hi Rob,
> 
>>> On Dec 30, 2021, at 4:03 PM, Eric Robinson 
>> wrote:
>>> 
>>> Chris,
>>> 
>>> If I want to ignore the vendor's recommendation and try connection
>> pooling anyway, is that something I can enable with a config file setting, 
>> or do
>> they actually have to trigger it from within their code?
>>> 
>> 

>> Up thread, didn’t you say tomcat was the client?  Are servlets in tomcat
>> making db requests?  What database system is under this?
>>> 
> 
> Yes, tomcat is the client and the database is MySQL. There are, in fact, many 
> tomcat instances on the same server, each connecting to its own dedicated 
> MySQL database located in a farm of MySQL servers.
> 

And then each tomcat instance has a single  identifying the db 
server?  It could be possible to redirect that Resource to a Connector/J 
fronting MySQL.  It would not be perfectly seamless but could be pretty quick, 
per tomcat instance.


 -Original Message-
 From: Eric Robinson >>> >
 Sent: Thursday, December 30, 2021 12:00 PM
 To: Tomcat Users List >>> >
 Subject: RE: Do I Need Network NameSpaces to Solve This
 Tomcat+Connector/J Problem?
 
 Chris,
 
> Not pooling connections will very likely negatively affect performance.
> 
> When you say "they ... have an issue with connection pooling" do you
> mean that they have a technical problem, or do you mean that there
> is some ill- conceived policy against them?
> 
> Oh, maybe they are paranoid about cross-client leakage between
> connections. Well, if the application can't be trusted not to leak
> that kind of info, then it can't be trusted to make the connections
> properly in the first place.
> 
> -chris
> 
 
 Hard to say what their issue is. We've asked about implementing it
 before, but they don't support it. You know how software companies
 are. Maybe they had a technical problem with it years ago and have just
>> not revisited it.
 They're stuck in a rut and there is too much inertia to get them out of it.
 
 --Eric
 
 
 
 
 Disclaimer : This email and any files transmitted with it are
 confidential and intended solely for intended recipients. If you are
 not the named addressee you should not disseminate, distribute, copy
 or alter this email. Any views or opinions presented in this email
 are solely those of the author and might not represent those of
 Physician Select Management. Warning: Although Physician Select
 Management has taken reasonable precautions to ensure no viruses are
 present in this email, the company cannot accept responsibility for any
>> loss or damage arising from the use of this email or attachments.
>>> Disclaimer : This email and any files transmitted with it are confidential 
>>> and
>> intended solely for intended recipients. If you are not the named addressee
>> you should not disseminate, distribute, copy or alter this email. Any views 
>> or
>> opinions presented in this email are solely those of the author and might not
>> represent those of Physician Select Management. Warning: Although
>> Physician Select Management has taken reasonable precautions to ensure
>> no viruses are present in this email, the company cannot accept 
>> responsibility
>> for any loss or damage arising from the use of this email or attachments.
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> 
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>> 
> Disclaimer : This email and any files transmitted with it are confidential 
> and intended solely for intended recipients. If you are not the named 
> addressee you should not disseminate, distribute, copy or alter this email. 
> Any views or opinions presented in this email are solely those of the author 
> and might not represent those of Physician Select Management. Warning: 
> Although Physician Select Management has taken reasonable precautions to 
> ensure no viruses are present in this email, the company cannot accept 
> responsibility for any loss or damage arising from the use of this email or 
> attachments.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org 
> 
> For additional commands, e-mail: users-h...@tomcat.apache.org 
> 

RE: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem?

[Eric Robinson]

Hi Rob,

> > On Dec 30, 2021, at 4:03 PM, Eric Robinson 
> wrote:
> >
> > Chris,
> >
> > If I want to ignore the vendor's recommendation and try connection
> pooling anyway, is that something I can enable with a config file setting, or 
> do
> they actually have to trigger it from within their code?
> >
>
> Up thread, didn’t you say tomcat was the client?  Are servlets in tomcat
> making db requests?  What database system is under this?
> >

Yes, tomcat is the client and the database is MySQL. There are, in fact, many 
tomcat instances on the same server, each connecting to its own dedicated MySQL 
database located in a farm of MySQL servers.

> >> -Original Message-
> >> From: Eric Robinson  >> >
> >> Sent: Thursday, December 30, 2021 12:00 PM
> >> To: Tomcat Users List  >> >
> >> Subject: RE: Do I Need Network NameSpaces to Solve This
> >> Tomcat+Connector/J Problem?
> >>
> >> Chris,
> >>
> >>> Not pooling connections will very likely negatively affect performance.
> >>>
> >>> When you say "they ... have an issue with connection pooling" do you
> >>> mean that they have a technical problem, or do you mean that there
> >>> is some ill- conceived policy against them?
> >>>
> >>> Oh, maybe they are paranoid about cross-client leakage between
> >>> connections. Well, if the application can't be trusted not to leak
> >>> that kind of info, then it can't be trusted to make the connections
> >>> properly in the first place.
> >>>
> >>> -chris
> >>>
> >>
> >> Hard to say what their issue is. We've asked about implementing it
> >> before, but they don't support it. You know how software companies
> >> are. Maybe they had a technical problem with it years ago and have just
> not revisited it.
> >> They're stuck in a rut and there is too much inertia to get them out of it.
> >>
> >> --Eric
> >>
> >>
> >>
> >>
> >> Disclaimer : This email and any files transmitted with it are
> >> confidential and intended solely for intended recipients. If you are
> >> not the named addressee you should not disseminate, distribute, copy
> >> or alter this email. Any views or opinions presented in this email
> >> are solely those of the author and might not represent those of
> >> Physician Select Management. Warning: Although Physician Select
> >> Management has taken reasonable precautions to ensure no viruses are
> >> present in this email, the company cannot accept responsibility for any
> loss or damage arising from the use of this email or attachments.
> > Disclaimer : This email and any files transmitted with it are confidential 
> > and
> intended solely for intended recipients. If you are not the named addressee
> you should not disseminate, distribute, copy or alter this email. Any views or
> opinions presented in this email are solely those of the author and might not
> represent those of Physician Select Management. Warning: Although
> Physician Select Management has taken reasonable precautions to ensure
> no viruses are present in this email, the company cannot accept responsibility
> for any loss or damage arising from the use of this email or attachments.
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > 
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> > 
Disclaimer : This email and any files transmitted with it are confidential and 
intended solely for intended recipients. If you are not the named addressee you 
should not disseminate, distribute, copy or alter this email. Any views or 
opinions presented in this email are solely those of the author and might not 
represent those of Physician Select Management. Warning: Although Physician 
Select Management has taken reasonable precautions to ensure no viruses are 
present in this email, the company cannot accept responsibility for any loss or 
damage arising from the use of this email or attachments.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem?

[Rob Sargent]

> On Dec 30, 2021, at 4:03 PM, Eric Robinson  wrote:
> 
> Chris,
> 
> If I want to ignore the vendor's recommendation and try connection pooling 
> anyway, is that something I can enable with a config file setting, or do they 
> actually have to trigger it from within their code?
> 

Up thread, didn’t you say tomcat was the client?  Are servlets in tomcat making 
db requests?  What database system is under this?
> 
>> -Original Message-
>> From: Eric Robinson > >
>> Sent: Thursday, December 30, 2021 12:00 PM
>> To: Tomcat Users List > >
>> Subject: RE: Do I Need Network NameSpaces to Solve This
>> Tomcat+Connector/J Problem?
>> 
>> Chris,
>> 
>>> Not pooling connections will very likely negatively affect performance.
>>> 
>>> When you say "they ... have an issue with connection pooling" do you
>>> mean that they have a technical problem, or do you mean that there is
>>> some ill- conceived policy against them?
>>> 
>>> Oh, maybe they are paranoid about cross-client leakage between
>>> connections. Well, if the application can't be trusted not to leak
>>> that kind of info, then it can't be trusted to make the connections
>>> properly in the first place.
>>> 
>>> -chris
>>> 
>> 
>> Hard to say what their issue is. We've asked about implementing it before,
>> but they don't support it. You know how software companies are. Maybe
>> they had a technical problem with it years ago and have just not revisited 
>> it.
>> They're stuck in a rut and there is too much inertia to get them out of it.
>> 
>> --Eric
>> 
>> 
>> 
>> 
>> Disclaimer : This email and any files transmitted with it are confidential 
>> and
>> intended solely for intended recipients. If you are not the named addressee
>> you should not disseminate, distribute, copy or alter this email. Any views 
>> or
>> opinions presented in this email are solely those of the author and might not
>> represent those of Physician Select Management. Warning: Although
>> Physician Select Management has taken reasonable precautions to ensure
>> no viruses are present in this email, the company cannot accept 
>> responsibility
>> for any loss or damage arising from the use of this email or attachments.
> Disclaimer : This email and any files transmitted with it are confidential 
> and intended solely for intended recipients. If you are not the named 
> addressee you should not disseminate, distribute, copy or alter this email. 
> Any views or opinions presented in this email are solely those of the author 
> and might not represent those of Physician Select Management. Warning: 
> Although Physician Select Management has taken reasonable precautions to 
> ensure no viruses are present in this email, the company cannot accept 
> responsibility for any loss or damage arising from the use of this email or 
> attachments.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org 
> 
> For additional commands, e-mail: users-h...@tomcat.apache.org 
> 

RE: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem?

[Eric Robinson]

Chris,

If I want to ignore the vendor's recommendation and try connection pooling 
anyway, is that something I can enable with a config file setting, or do they 
actually have to trigger it from within their code?


> -Original Message-
> From: Eric Robinson 
> Sent: Thursday, December 30, 2021 12:00 PM
> To: Tomcat Users List 
> Subject: RE: Do I Need Network NameSpaces to Solve This
> Tomcat+Connector/J Problem?
>
> Chris,
>
> > Not pooling connections will very likely negatively affect performance.
> >
> > When you say "they ... have an issue with connection pooling" do you
> > mean that they have a technical problem, or do you mean that there is
> > some ill- conceived policy against them?
> >
> > Oh, maybe they are paranoid about cross-client leakage between
> > connections. Well, if the application can't be trusted not to leak
> > that kind of info, then it can't be trusted to make the connections
> > properly in the first place.
> >
> > -chris
> >
>
> Hard to say what their issue is. We've asked about implementing it before,
> but they don't support it. You know how software companies are. Maybe
> they had a technical problem with it years ago and have just not revisited it.
> They're stuck in a rut and there is too much inertia to get them out of it.
>
> --Eric
>
>
>
>
> Disclaimer : This email and any files transmitted with it are confidential and
> intended solely for intended recipients. If you are not the named addressee
> you should not disseminate, distribute, copy or alter this email. Any views or
> opinions presented in this email are solely those of the author and might not
> represent those of Physician Select Management. Warning: Although
> Physician Select Management has taken reasonable precautions to ensure
> no viruses are present in this email, the company cannot accept responsibility
> for any loss or damage arising from the use of this email or attachments.
Disclaimer : This email and any files transmitted with it are confidential and 
intended solely for intended recipients. If you are not the named addressee you 
should not disseminate, distribute, copy or alter this email. Any views or 
opinions presented in this email are solely those of the author and might not 
represent those of Physician Select Management. Warning: Although Physician 
Select Management has taken reasonable precautions to ensure no viruses are 
present in this email, the company cannot accept responsibility for any loss or 
damage arising from the use of this email or attachments.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: javax.servlet vs jakarta.servlet?

[Michael B Allen]

On Thu, Dec 30, 2021 at 10:57 AM Christopher Schultz
 wrote:
>
> You mean like ServletContext.getRealPath?

Honestly I'm not sure how I feel about getRealPath. On the one hand, I
don't think it's reasonable to just pretend that applications only
exist in the vacuum of space. There are many practical reasons why an
application might want to interact with the filesystem but without
requiring absolute paths. Just because there might not be a file
system is a weak excuse to not properly account for one. Being able to
update a file of properties for example and have the application see
that the file is updated without reloading the webapp (maybe even if
the app is packaged as a war) is very useful. On the other hand I
don't think I would want another 10 classes just to create some kind
of ancillary webapp storage abstraction.

Mike

-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem?

[José Cornado]

https://tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/chap6sec70.html

Mentions “tcp and udp traffic” it seems across all processes

On Thu, Dec 30, 2021 at 11:49 AM Eric Robinson 
wrote:

> José,
>
> > -Original Message-
> > From: José Cornado 
> > Sent: Thursday, December 30, 2021 12:00 PM
> > To: Tomcat Users List 
> > Subject: Re: Do I Need Network NameSpaces to Solve This
> > Tomcat+Connector/J Problem?
> >
> > But they do not get a corresponding database instance?
> >
>
> They do. Each tomcat instance has a corresponding database instance
> listening on its own dedicated port. Even so, we've seen cases where all
> the available client ports are exhausted.
>
> This raises the question, does the Linux ip_local_port_range shown here...
>
> $ cat /proc/sys/net/ipv4/ip_local_port_range
> 32768   61000
>
> ...apply globally, or on a per-socket basis? I would think that it should
> apply per socket, but in practice it seems to be a global limitation.
>
> -Eric
>
>
> Disclaimer : This email and any files transmitted with it are confidential
> and intended solely for intended recipients. If you are not the named
> addressee you should not disseminate, distribute, copy or alter this email.
> Any views or opinions presented in this email are solely those of the
> author and might not represent those of Physician Select Management.
> Warning: Although Physician Select Management has taken reasonable
> precautions to ensure no viruses are present in this email, the company
> cannot accept responsibility for any loss or damage arising from the use of
> this email or attachments.
>

RE: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem?

[Eric Robinson]

> José,
>
> > -Original Message-
> > From: José Cornado 
> > Sent: Thursday, December 30, 2021 12:00 PM
> > To: Tomcat Users List 
> > Subject: Re: Do I Need Network NameSpaces to Solve This
> > Tomcat+Connector/J Problem?
> >
> > But they do not get a corresponding database instance?
> >
>
> They do. Each tomcat instance has a corresponding database instance
> listening on its own dedicated port. Even so, we've seen cases where all the
> available client ports are exhausted.
>
> This raises the question, does the Linux ip_local_port_range shown here...
>
> $ cat /proc/sys/net/ipv4/ip_local_port_range
> 32768   61000
>
> ...apply globally, or on a per-socket basis? I would think that it should 
> apply
> per socket, but in practice it seems to be a global limitation.
>
> -Eric
>
>

I need to correct myself. My testing confirms that it is per-socket.

-Eric
Disclaimer : This email and any files transmitted with it are confidential and 
intended solely for intended recipients. If you are not the named addressee you 
should not disseminate, distribute, copy or alter this email. Any views or 
opinions presented in this email are solely those of the author and might not 
represent those of Physician Select Management. Warning: Although Physician 
Select Management has taken reasonable precautions to ensure no viruses are 
present in this email, the company cannot accept responsibility for any loss or 
damage arising from the use of this email or attachments.

RE: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem?

[Eric Robinson]

José,

> -Original Message-
> From: José Cornado 
> Sent: Thursday, December 30, 2021 12:00 PM
> To: Tomcat Users List 
> Subject: Re: Do I Need Network NameSpaces to Solve This
> Tomcat+Connector/J Problem?
>
> But they do not get a corresponding database instance?
>

They do. Each tomcat instance has a corresponding database instance listening 
on its own dedicated port. Even so, we've seen cases where all the available 
client ports are exhausted.

This raises the question, does the Linux ip_local_port_range shown here...

$ cat /proc/sys/net/ipv4/ip_local_port_range
32768   61000

...apply globally, or on a per-socket basis? I would think that it should apply 
per socket, but in practice it seems to be a global limitation.

-Eric


Disclaimer : This email and any files transmitted with it are confidential and 
intended solely for intended recipients. If you are not the named addressee you 
should not disseminate, distribute, copy or alter this email. Any views or 
opinions presented in this email are solely those of the author and might not 
represent those of Physician Select Management. Warning: Although Physician 
Select Management has taken reasonable precautions to ensure no viruses are 
present in this email, the company cannot accept responsibility for any loss or 
damage arising from the use of this email or attachments.

Re: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem?

[José Cornado]

But they do not get a corresponding database instance?

On Thu, Dec 30, 2021 at 10:51 AM Eric Robinson 
wrote:

> José,
>
> > Is this setup going to be open to the world or just a big organization?
> A big
> > organization would put a cap on the number of users. Then maybe they
> > could divide those between the tomcat instances thus the db server.
> >
>
> It's a SaaS solution, where each customer organization gets its own tomcat
> instance.
>
> -Eric
>
>
>
> Disclaimer : This email and any files transmitted with it are confidential
> and intended solely for intended recipients. If you are not the named
> addressee you should not disseminate, distribute, copy or alter this email.
> Any views or opinions presented in this email are solely those of the
> author and might not represent those of Physician Select Management.
> Warning: Although Physician Select Management has taken reasonable
> precautions to ensure no viruses are present in this email, the company
> cannot accept responsibility for any loss or damage arising from the use of
> this email or attachments.
>

RE: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem?

[Eric Robinson]

Chris,

> Not pooling connections will very likely negatively affect performance.
>
> When you say "they ... have an issue with connection pooling" do you mean
> that they have a technical problem, or do you mean that there is some ill-
> conceived policy against them?
>
> Oh, maybe they are paranoid about cross-client leakage between
> connections. Well, if the application can't be trusted not to leak that kind 
> of
> info, then it can't be trusted to make the connections properly in the first
> place.
>
> -chris
>

Hard to say what their issue is. We've asked about implementing it before, but 
they don't support it. You know how software companies are. Maybe they had a 
technical problem with it years ago and have just not revisited it. They're 
stuck in a rut and there is too much inertia to get them out of it.

--Eric




Disclaimer : This email and any files transmitted with it are confidential and 
intended solely for intended recipients. If you are not the named addressee you 
should not disseminate, distribute, copy or alter this email. Any views or 
opinions presented in this email are solely those of the author and might not 
represent those of Physician Select Management. Warning: Although Physician 
Select Management has taken reasonable precautions to ensure no viruses are 
present in this email, the company cannot accept responsibility for any loss or 
damage arising from the use of this email or attachments.

RE: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem?

[Eric Robinson]

Chris,

> Stupid question: can your database (meaningfully) handle the number of
> connections you are making to it? Let's say you have 5000 connections per
> Tomcat instance to your database, and you want 500 Tomcat instances.
> That means 250 database connections. If every single one of those is
> executing a query, will your database melt or are you okay?
>
> Are you pooling database connections? Are you sure you need thousands-at-
> a-time for each Tomcat instance?
>
> I'm not saying that you absolutely /do not/ need this kind of thing, but "most
> people" don't need that kind of concurrency.
>

A fair question. The load is spread over multiple database servers, and they 
are capable of handling the connection count. The problem we've encountered in 
the past was on the client side, where it would exhaust the available client 
ports. We alleviated that by increasing the client port range, but the problem 
will return when we quintuple the tomcat instance count.

--Eric


Disclaimer : This email and any files transmitted with it are confidential and 
intended solely for intended recipients. If you are not the named addressee you 
should not disseminate, distribute, copy or alter this email. Any views or 
opinions presented in this email are solely those of the author and might not 
represent those of Physician Select Management. Warning: Although Physician 
Select Management has taken reasonable precautions to ensure no viruses are 
present in this email, the company cannot accept responsibility for any loss or 
damage arising from the use of this email or attachments.

RE: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem?

[Eric Robinson]

Stefan,

> A third option could be to add something between database client and
> server. Something on layer 4 like multiple HAProxy servers or simple NAT
> gateways. Or more complex on layer 7 specfic products like ProxySQL or
> MaxScale. They could even pool connections and reduce the load on the
> database server. But this all adds complexity and new ways to fail.
>
> The easiest solution in terms of implementation and operation is the one
> Mark suggested: add multiple ip addresses and/or ports to your database
> listener.
>
> Regards,
>
>Stefan
>

My original idea was to add multiple source IPs to the app server. Mark's 
suggestion is similar, except we would change the destination IPs. Either way, 
it opens up the opportunity to have more unique sockets. Both suggestions would 
work. I'm just wondering if there is something I can do with network namespaces 
that would be even better. I don't have any experience with using it.

-Eric


Disclaimer : This email and any files transmitted with it are confidential and 
intended solely for intended recipients. If you are not the named addressee you 
should not disseminate, distribute, copy or alter this email. Any views or 
opinions presented in this email are solely those of the author and might not 
represent those of Physician Select Management. Warning: Although Physician 
Select Management has taken reasonable precautions to ensure no viruses are 
present in this email, the company cannot accept responsibility for any loss or 
damage arising from the use of this email or attachments.

RE: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem?

[Eric Robinson]

José,

> Is this setup going to be open to the world or just a big organization? A big
> organization would put a cap on the number of users. Then maybe they
> could divide those between the tomcat instances thus the db server.
>

It's a SaaS solution, where each customer organization gets its own tomcat 
instance.

-Eric



Disclaimer : This email and any files transmitted with it are confidential and 
intended solely for intended recipients. If you are not the named addressee you 
should not disseminate, distribute, copy or alter this email. Any views or 
opinions presented in this email are solely those of the author and might not 
represent those of Physician Select Management. Warning: Although Physician 
Select Management has taken reasonable precautions to ensure no viruses are 
present in this email, the company cannot accept responsibility for any loss or 
damage arising from the use of this email or attachments.

RE: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem?

[Eric Robinson]

Mark,

> > My question is, is there a better way?
>
> I can only think of variations on a theme.
>
> The ~64k limit assumes client IP, server IP and server port remain constant.
> i.e. just client port is varying.
>
> That suggests there is a single IP for the database server and that it is
> listening on a single port.
>
> You are currently varying client IP. Varying server IP is unlikely to be any
> different in terms of ease of management etc.
>
> There may be more mileage in getting the database server to listen on more
> than one port. It depends how the database sever is structured. If it can have
> multiple listeners all passing connections to the same database instance then
> adding db listeners might be a simpler way to manage this.
>
> Mark

In reality, there are multiple database servers. Even so, we have seen cases 
where the vendor software consumed huge numbers of TCP connections rapidly due 
to some function of the java code, and started throwing errors about not being 
able to open sockets. We alleviated the issue by increasing the number of 
available client ports, but there were less than 100 tomcat instances on the 
app server. When we increase the count to 500, the problem will reappear unless 
we can figure out a way to distribute client port usage. That's why I came up 
with the idea of using multiple source IPs on the app server. I am new to 
network namespaces, and thought that might be a better solution, but I have no 
experience with it.

-Eric


Disclaimer : This email and any files transmitted with it are confidential and 
intended solely for intended recipients. If you are not the named addressee you 
should not disseminate, distribute, copy or alter this email. Any views or 
opinions presented in this email are solely those of the author and might not 
represent those of Physician Select Management. Warning: Although Physician 
Select Management has taken reasonable precautions to ensure no viruses are 
present in this email, the company cannot accept responsibility for any loss or 
damage arising from the use of this email or attachments.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem?

[Eric Robinson]

Hi Simon,


> I guess the database is not on the Tomcat host, otherwise you could connect
> via unix domain socket to avoid the limitations of TCP port numbers.
>
> Otherwise I think you could run a db proxy where your Tomcat clients
> connect locally via unix domain socket and the proxy relays the queries to the
> db backend.
>
> Regards,
> Simon
>

Your guess is correct.

-Eric

Disclaimer : This email and any files transmitted with it are confidential and 
intended solely for intended recipients. If you are not the named addressee you 
should not disseminate, distribute, copy or alter this email. Any views or 
opinions presented in this email are solely those of the author and might not 
represent those of Physician Select Management. Warning: Although Physician 
Select Management has taken reasonable precautions to ensure no viruses are 
present in this email, the company cannot accept responsibility for any loss or 
damage arising from the use of this email or attachments.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [OT] log4net.dll CVE too ?

[Christopher Schultz]

Phillipe,

Note that this is a mailing list for Apache Tomcat which is a Java Web 
Servlet Container (among a few other things). This mailing list has 
nothing to do with logging, .NET, or logging in .NET.


That said...

On 12/30/21 11:23, Philippe Couas wrote:

log4net.dll seems too havre problem


Does it?


where could i found last version for windows 10 ?


Same place you could always get it:
https://logging.apache.org/log4net/download_log4net.html

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem?

[Christopher Schultz]

Eric,

On 12/29/21 19:23, Eric Robinson wrote:

-Original Message-
From: Mark Eggers 
Sent: Wednesday, December 29, 2021 6:18 PM
To: users@tomcat.apache.org
Subject: Re: Do I Need Network NameSpaces to Solve This
Tomcat+Connector/J Problem?

Eric:

On 12/29/2021 1:04 PM, Eric Robinson wrote:

We want to run a large number of tomcat instances on the same server

without virtualization or containerization. Each instance is executed from its
own folder tree and listens on its own unique TCP port. Each instance will run
code that connects to a backend database server to send queries that are
triggered by JSP calls from users. We've done this successfully with up to 120
instances of tomcat running on the same server while avoiding the overhead
of virtualization and the complexity of containers. Based on our experience
over the past decade, we know that we could potentially host 500 or more
separate tomcat instances on the same server without running into
performance problems. So now we want to make it 500 parallel instances.



Here's the problem. When tomcat initiates an outbound connection (for

example, with Connector/J to query a backend database) it establishes a
socket, and the socket has a client port. With thousands of users making
requests that require the tomcat services to query back end databases, the
OS can easily run out of available client ports to allocate to sockets. To avoid
that problem, we can assign multiple IPs to the server and use the
localSocketAddress property of Connector/J to group tomcats such that only
a subset of them each use the same source IP. Then each group will have its
own range of 64,000-ish client ports. I've tested this and it works.




My question is, is there a better way?


Are you using database connection pooling? If you are, wouldn't the
outbound connections to the database from a particular Tomcat be limited to
the maxTotal in your context.xml (maxActive in Tomcat 7).

So unless you're using a huge pool, wouldn't the required number of
outbound ports be fairly small?

. . . just my two cents
/mde/


Unfortunately, we are under vendor constraints. They apparently have an issue 
with connection pooling.


Not pooling connections will very likely negatively affect performance.

When you say "they ... have an issue with connection pooling" do you 
mean that they have a technical problem, or do you mean that there is 
some ill-conceived policy against them?


Oh, maybe they are paranoid about cross-client leakage between 
connections. Well, if the application can't be trusted not to leak that 
kind of info, then it can't be trusted to make the connections properly 
in the first place.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem?

[Christopher Schultz]

Eric,

On 12/29/21 16:04, Eric Robinson wrote:
We want to run a large number of tomcat instances on the same server 
without virtualization or containerization. Each instance is executed 
from its own folder tree and listens on its own unique TCP port. Each 
instance will run code that connects to a backend database server to 
send queries that are triggered by JSP calls from users. We’ve done this 
successfully with up to 120 instances of tomcat running on the same 
server while avoiding the overhead of virtualization and the complexity 
of containers. Based on our experience over the past decade, we know 
that we could potentially host 500 or more separate tomcat instances on 
the same server without running into performance problems. So now we 
want to make it 500 parallel instances.


Here’s the problem. When tomcat initiates an outbound connection (for 
example, with Connector/J to query a backend database) it establishes a 
socket, and the socket has a client port. With thousands of users making 
requests that require the tomcat services to query back end databases, 
the OS can easily run out of available client ports to allocate to 
sockets. To avoid that problem, we can assign multiple IPs to the server 
and use the localSocketAddress property of Connector/J to group tomcats 
such that only a subset of them each use the same source IP. Then each 
group will have its own range of 64,000-ish client ports. I’ve tested 
this and it works.


My question is, is there a better way?


Stupid question: can your database (meaningfully) handle the number of 
connections you are making to it? Let's say you have 5000 connections 
per Tomcat instance to your database, and you want 500 Tomcat instances. 
That means 250 database connections. If every single one of those is 
executing a query, will your database melt or are you okay?


Are you pooling database connections? Are you sure you need 
thousands-at-a-time for each Tomcat instance?


I'm not saying that you absolutely /do not/ need this kind of thing, but 
"most people" don't need that kind of concurrency.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem?

[Stefan Mayr]

Am 30.12.2021 um 12:24 schrieb Mark Thomas:

On 29/12/2021 21:04, Eric Robinson wrote:




My question is, is there a better way?


I can only think of variations on a theme.

The ~64k limit assumes client IP, server IP and server port remain 
constant. i.e. just client port is varying.


That suggests there is a single IP for the database server and that it 
is listening on a single port.


You are currently varying client IP. Varying server IP is unlikely to be 
any different in terms of ease of management etc.


There may be more mileage in getting the database server to listen on 
more than one port. It depends how the database sever is structured. If 
it can have multiple listeners all passing connections to the same 
database instance then adding db listeners might be a simpler way to 
manage this.


Mark


A third option could be to add something between database client and 
server. Something on layer 4 like multiple HAProxy servers or simple NAT 
gateways. Or more complex on layer 7 specfic products like ProxySQL or 
MaxScale. They could even pool connections and reduce the load on the 
database server. But this all adds complexity and new ways to fail.


The easiest solution in terms of implementation and operation is the one 
Mark suggested: add multiple ip addresses and/or ports to your database 
listener.


Regards,

  Stefan

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

log4net.dll CVE too ?

[Philippe Couas]

Hi

 

log4net.dll seems too havre problem, where could i found last version for 
windows 10 ?

 

Regards

Phil

Re: issue with Form based authentication

[Christopher Schultz]

Mark, Rajendra,

On 12/30/21 06:13, Mark Thomas wrote:

This is an application design issue, not a Tomcat issue.

FORM auth is not intended / designed to work in the following scenario:
- user is not authenticated
- multiple, concurrent requests are made for resources requiring
   authentication

You need to design the application in such a way that once 
authentication is triggered, no further requests are made until 
authentication is complete.


+1

An easy way to do this is to make sure that all requests for static 
resources such as images, etc. are explicitly defined to NOT require any 
authentication, perhaps like this:


  

  unauthenticated-stuff
  /path/to/static/a/*
  /path/to/static/a/*
  /path/to/static/b/*
  ...


  

-chris


On 30/12/2021 11:02, Rathore, Rajendra wrote:

Link for image where it will shows the details

https://docs.google.com/document/d/1Ziojwm6rPvyuJ6rpJR1tu0e5xTfnawrHeLz3QvL28XA/edit?usp=sharing 




Thanks and Regards,
Rajendra Rathore
9922701491

From: Rathore, Rajendra
Sent: Thursday, December 30, 2021 4:25 PM
To: users@tomcat.apache.org
Subject: issue with Form based authentication
Importance: High

Hi Team,

We are facing some weird issue with tomcat Form based authentication, 
I will try to explain the scenario as below:


issue is reproducible in specific conditions, when browser cache is 
disabled, and cleared out before session timeout. In this conditions 
after session timeout when user is moving mouse over some elements 
where requests for GIFs are sent. Those request are processed by 
FormAuthenticator tomcat class. This class is responsible for saving 
requested URL and redirecting user to this saved URL after successful 
login. But this class saves in session all requests using the same 
key, this means that old requests are overrided by new ones. In this 
case there are multiple requests after session timeout, to get some 
GIFs, and to show relogin.jsp in popup window, those requests are 
handled by different threads, and last executed thread is saving to 
session information about requested URL. We have classic race 
condition here. If relogin.jsp will be requested last, then issue is 
not reproducible, if some GIF will be requested and saved last issue 
will be reproducible.


Please let me know if any extra loggers required, will enable and 
shared with you.


Thanks and Regards,
Rajendra Rathore




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: javax.servlet vs jakarta.servlet?

[Christopher Schultz]

Michael,

On 12/29/21 14:54, Michael B Allen wrote:

On Wed, Dec 29, 2021 at 2:07 PM Mark Thomas  wrote:

One of the advantages of moving to Eclipse is that everyone involved in
the spec, not just the spec lead, has an equal say in what goes into the
spec.


That sounds like design by committee which is my concern. IMO the only
way to design a really good API is for one individual with a vision to
just write it, use it, exercise it and then see what works and what
does not. I routinely re-write things multiple times very slowly
before settling on an API. It's exponentially harder for multiple
people to have the same vision. Design by committee can easily
degenerate into an overly-OOP set of interfaces and classes and enums
to define an API that doesn't actually do that much. Once you lock
into an API, that could be used for decades. So even the slightest
mistake can create seams that transcend every codebase that uses it
with long term consequences.


You mean like ServletContext.getRealPath?

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem?

[José Cornado]

Is this setup going to be open to the world or just a big organization? A
big organization would put a cap on the number of users. Then maybe they
could divide those between the tomcat instances thus the db server.



On Thu, Dec 30, 2021 at 4:24 AM Mark Thomas  wrote:

> On 29/12/2021 21:04, Eric Robinson wrote:
>
> 
>
> > My question is, is there a better way?
>
> I can only think of variations on a theme.
>
> The ~64k limit assumes client IP, server IP and server port remain
> constant. i.e. just client port is varying.
>
> That suggests there is a single IP for the database server and that it
> is listening on a single port.
>
> You are currently varying client IP. Varying server IP is unlikely to be
> any different in terms of ease of management etc.
>
> There may be more mileage in getting the database server to listen on
> more than one port. It depends how the database sever is structured. If
> it can have multiple listeners all passing connections to the same
> database instance then adding db listeners might be a simpler way to
> manage this.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem?

[Mark Thomas]

On 29/12/2021 21:04, Eric Robinson wrote:




My question is, is there a better way?


I can only think of variations on a theme.

The ~64k limit assumes client IP, server IP and server port remain 
constant. i.e. just client port is varying.


That suggests there is a single IP for the database server and that it 
is listening on a single port.


You are currently varying client IP. Varying server IP is unlikely to be 
any different in terms of ease of management etc.


There may be more mileage in getting the database server to listen on 
more than one port. It depends how the database sever is structured. If 
it can have multiple listeners all passing connections to the same 
database instance then adding db listeners might be a simpler way to 
manage this.


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: issue with Form based authentication

[Mark Thomas]

This is an application design issue, not a Tomcat issue.

FORM auth is not intended / designed to work in the following scenario:
- user is not authenticated
- multiple, concurrent requests are made for resources requiring
  authentication

You need to design the application in such a way that once 
authentication is triggered, no further requests are made until 
authentication is complete.


Mark


On 30/12/2021 11:02, Rathore, Rajendra wrote:

Link for image where it will shows the details

https://docs.google.com/document/d/1Ziojwm6rPvyuJ6rpJR1tu0e5xTfnawrHeLz3QvL28XA/edit?usp=sharing


Thanks and Regards,
Rajendra Rathore
9922701491

From: Rathore, Rajendra
Sent: Thursday, December 30, 2021 4:25 PM
To: users@tomcat.apache.org
Subject: issue with Form based authentication
Importance: High

Hi Team,

We are facing some weird issue with tomcat Form based authentication, I will 
try to explain the scenario as below:

issue is reproducible in specific conditions, when browser cache is disabled, 
and cleared out before session timeout. In this conditions after session 
timeout when user is moving mouse over some elements where requests for GIFs 
are sent. Those request are processed by FormAuthenticator tomcat class. This 
class is responsible for saving requested URL and redirecting user to this 
saved URL after successful login. But this class saves in session all requests 
using the same key, this means that old requests are overrided by new ones. In 
this case there are multiple requests after session timeout, to get some GIFs, 
and to show relogin.jsp in popup window, those requests are handled by 
different threads, and last executed thread is saving to session information 
about requested URL. We have classic race condition here. If relogin.jsp will 
be requested last, then issue is not reproducible, if some GIF will be 
requested and saved last issue will be reproducible.

Please let me know if any extra loggers required, will enable and shared with 
you.

Thanks and Regards,
Rajendra Rathore




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: issue with Form based authentication

[Rathore, Rajendra]

Link for image where it will shows the details

https://docs.google.com/document/d/1Ziojwm6rPvyuJ6rpJR1tu0e5xTfnawrHeLz3QvL28XA/edit?usp=sharing


Thanks and Regards,
Rajendra Rathore
9922701491

From: Rathore, Rajendra
Sent: Thursday, December 30, 2021 4:25 PM
To: users@tomcat.apache.org
Subject: issue with Form based authentication
Importance: High

Hi Team,

We are facing some weird issue with tomcat Form based authentication, I will 
try to explain the scenario as below:

issue is reproducible in specific conditions, when browser cache is disabled, 
and cleared out before session timeout. In this conditions after session 
timeout when user is moving mouse over some elements where requests for GIFs 
are sent. Those request are processed by FormAuthenticator tomcat class. This 
class is responsible for saving requested URL and redirecting user to this 
saved URL after successful login. But this class saves in session all requests 
using the same key, this means that old requests are overrided by new ones. In 
this case there are multiple requests after session timeout, to get some GIFs, 
and to show relogin.jsp in popup window, those requests are handled by 
different threads, and last executed thread is saving to session information 
about requested URL. We have classic race condition here. If relogin.jsp will 
be requested last, then issue is not reproducible, if some GIF will be 
requested and saved last issue will be reproducible.

Please let me know if any extra loggers required, will enable and shared with 
you.

Thanks and Regards,
Rajendra Rathore

issue with Form based authentication

[Rathore, Rajendra]

Hi Team,

We are facing some weird issue with tomcat Form based authentication, I will 
try to explain the scenario as below:

issue is reproducible in specific conditions, when browser cache is disabled, 
and cleared out before session timeout. In this conditions after session 
timeout when user is moving mouse over some elements where requests for GIFs 
are sent. Those request are processed by FormAuthenticator tomcat class. This 
class is responsible for saving requested URL and redirecting user to this 
saved URL after successful login. But this class saves in session all requests 
using the same key, this means that old requests are overrided by new ones. In 
this case there are multiple requests after session timeout, to get some GIFs, 
and to show relogin.jsp in popup window, those requests are handled by 
different threads, and last executed thread is saving to session information 
about requested URL. We have classic race condition here. If relogin.jsp will 
be requested last, then issue is not reproducible, if some GIF will be 
requested and saved last issue will be reproducible.

Please let me know if any extra loggers required, will enable and shared with 
you.

Thanks and Regards,
Rajendra Rathore

Re: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem?

[Simon Matter]

Hi,

> We want to run a large number of tomcat instances on the same server
> without virtualization or containerization. Each instance is executed from
> its own folder tree and listens on its own unique TCP port. Each instance
> will run code that connects to a backend database server to send queries
> that are triggered by JSP calls from users. We've done this successfully
> with up to 120 instances of tomcat running on the same server while
> avoiding the overhead of virtualization and the complexity of containers.
> Based on our experience over the past decade, we know that we could
> potentially host 500 or more separate tomcat instances on the same server
> without running into performance problems. So now we want to make it 500
> parallel instances.
>
>
> Here's the problem. When tomcat initiates an outbound connection (for
> example, with Connector/J to query a backend database) it establishes a
> socket, and the socket has a client port. With thousands of users making
> requests that require the tomcat services to query back end databases, the
> OS can easily run out of available client ports to allocate to sockets. To
> avoid that problem, we can assign multiple IPs to the server and use the
> localSocketAddress property of Connector/J to group tomcats such that only
> a subset of them each use the same source IP. Then each group will have
> its own range of 64,000-ish client ports. I've tested this and it works.
>
>
>
> My question is, is there a better way?

I guess the database is not on the Tomcat host, otherwise you could
connect via unix domain socket to avoid the limitations of TCP port
numbers.

Otherwise I think you could run a db proxy where your Tomcat clients
connect locally via unix domain socket and the proxy relays the queries to
the db backend.

Regards,
Simon


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org