Re: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem?
Eric, On 1/4/22 00:08, Eric Robinson wrote: We have access to the configuration files, but not the source code. There is no "pool" reference in server.xml or any of the context.xml files. You would want to look for . However, I did receive a call from a vendor tech this morning and they are exploring the question right now and will get back to me soon hopefully. Sounds hopeful. I'd be interested to hear what the original justification was for not using pooling. -chris -Original Message- From: Christopher Schultz Sent: Monday, January 3, 2022 9:10 AM To: users@tomcat.apache.org Subject: Re: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem? Eric, On 12/30/21 19:03, Eric Robinson wrote: 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? That depends upon how they are obtaining database connections. If they are using the driver directly and NOT using a pool (why would they use a pool if they have a policy NOT to use it?) then there is likely nothing you can do. Are you able to look at the code? Are you able to look at the configuration? Specifically, the META-INF/context.xml file in the application and conf/server.xml for the server. If we can find a "pool" configuration in there, it's possible it just has insane limits like maxActive="10" or something like that. -chris -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 - 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 comman
RE: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem?
Hi Chris -- We have access to the configuration files, but not the source code. There is no "pool" reference in server.xml or any of the context.xml files. However, I did receive a call from a vendor tech this morning and they are exploring the question right now and will get back to me soon hopefully. > -Original Message- > From: Christopher Schultz > Sent: Monday, January 3, 2022 9:10 AM > To: users@tomcat.apache.org > Subject: Re: Do I Need Network NameSpaces to Solve This > Tomcat+Connector/J Problem? > > Eric, > > On 12/30/21 19:03, Eric Robinson wrote: > > 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? > That depends upon how they are obtaining database connections. If they are > using the driver directly and NOT using a pool (why would they use a pool if > they have a policy NOT to use it?) then there is likely nothing you can do. > > Are you able to look at the code? Are you able to look at the configuration? > Specifically, the META-INF/context.xml file in the application and > conf/server.xml for the server. > > If we can find a "pool" configuration in there, it's possible it just has > insane > limits like maxActive="10" or something like that. > > -chris > > >> -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 > > > > - > 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 a
Re: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem?
Eric, On 12/30/21 19:03, Eric Robinson wrote: 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? That depends upon how they are obtaining database connections. If they are using the driver directly and NOT using a pool (why would they use a pool if they have a policy NOT to use it?) then there is likely nothing you can do. Are you able to look at the code? Are you able to look at the configuration? Specifically, the META-INF/context.xml file in the application and conf/server.xml for the server. If we can find a "pool" configuration in there, it's possible it just has insane limits like maxActive="10" or something like that. -chris -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 - 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?
> 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 >>> <mailto:eric.robin...@psmnv.com>> >>>> Sent: Thursday, December 30, 2021 12:00 PM >>>> To: Tomcat Users List >>> <mailto:users@tomcat.apache.org>> >>>> 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 >>> <mailto:users-unsubscr...@tomcat.apache.org> >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> <mailto: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 > <mailto:users-unsubscr...@tomcat.apache.org> > For additional commands, e-mail: users-h...@tomcat.apache.org > <mailto:users-h...@tomcat.apache.org>
RE: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem?
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 >> <mailto:eric.robin...@psmnv.com>> > >> Sent: Thursday, December 30, 2021 12:00 PM > >> To: Tomcat Users List >> <mailto:users@tomcat.apache.org>> > >> 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 > > <mailto:users-unsubscr...@tomcat.apache.org> > > For additional commands, e-mail: users-h...@tomcat.apache.org > > <mailto: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?
> 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 > <mailto:eric.robin...@psmnv.com>> >> Sent: Thursday, December 30, 2021 12:00 PM >> To: Tomcat Users List > <mailto:users@tomcat.apache.org>> >> 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 > <mailto:users-unsubscr...@tomcat.apache.org> > For additional commands, e-mail: users-h...@tomcat.apache.org > <mailto:users-h...@tomcat.apache.org>
RE: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem?
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: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem?
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?
> 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?
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?
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?
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?
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?
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?
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?
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?
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: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem?
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?
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?
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
Re: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem?
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?
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?
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
RE: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem?
> Your problem seems to be in the client-to-db server side of things. Not > tomcat as a server. > In the context of this question, tomcat is the client. > On Wed, Dec 29, 2021 at 2:11 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? > > > > > > > > > > > > <113> > > > > > > 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?
> -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. -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: 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/ OpenPGP_signature Description: OpenPGP digital signature
Re: Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem?
Your problem seems to be in the client-to-db server side of things. Not tomcat as a server. On Wed, Dec 29, 2021 at 2:11 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? > > > > > > <113> > > > 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. >
Do I Need Network NameSpaces to Solve This Tomcat+Connector/J Problem?
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? [cid:image001.png@01D7FCC2.42FAB2E0] 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.
