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. >
Re: ClassFileTransformer in Tomcat 10 common classloader
On 28.12.21 00:36, Chew Kok Hoor wrote: We're using the old javax.servlet namespace for compatibility reasons. Some of our jar files are re-used by different web-apps, therefore we placed them in the common classloader. Is it possible to convert them dynamically, just like how we do it for servlets in the per app WEB-INF folder, by using the following in the context file: I have a similar situation. I run two sites on different servers. Today I upgraded to TC 9.0.56 on both without incident. (I do the upgrades manually from the tar.gz files). However, in keeping up with where things are going, I also run a development copy of the latest 10 (currently 10.0.14). Initially I ran the offline converter, but as my main applications are still running in production under 9.0.x, I don't really want to convert them from javax.servlet to jakarta.servlet just yet. My overall deployments are quite simple. I don't modify much on a stock download of tomcat - just server.xml (to add HTTPS support for my certs) and web.xml (to force HTTPS). Maybe 10 lines different in both files. My libraries for the applications are now stored in webapps rather than the common library area, but ALL my stuff still run javax.servlet. I found that by adding the single line " " after the in the main conf/context.xml file, everything auto-converts and runs perfectly. Frankly, for my purposes, this has to be the simplest solution. Cheers, -R -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- This communication is intended for the use of the recipient to whom it is addressed, and may contain confidential, personal, and or privileged information. Please contact us immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take action relying on it. Any communications received in error, or subsequent reply, should be deleted or destroyed. --- - 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?
On 12/29/2021 2:54 PM, 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. I think the chances of a single person missing something useful or important are greater than the chance of a *small* committee over-designing the API. You are correct that CORBA was a big mess due to its design by a huge committee, but a smaller group has done will with most java APIs. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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.
Re: javax.servlet vs jakarta.servlet?
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. But I suppose this is thoroughly off topic at this point. Thanks for your help, Mike -- 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: javax.servlet vs jakarta.servlet?
On 29/12/2021 15:55, Michael B Allen wrote: On Tue, Dec 28, 2021 at 10:52 AM Mark Thomas wrote: Actually it seems the migration tool behind this feature: https://github.com/apache/tomcat-jakartaee-migration is a better and more general solution. If it's just re-writing package names, can any jar converted using the tomcat-jakartaee-migration tool be used with another app server like Jetty 11? Yes. When Tomcat 10.x reaches end of life (~2030) 9.10.x releases will stop and 9.11.x releases will start. These will essentially track Tomcat 11.x releases but with the Java EE API rather than the Jakarta EE API. And so on for as long as there is community demand for the Java EE support and there are 3 Tomcat PMC members willing to vote for the release. That is encouraging. So just to be crystal clear, Tomcat 9 will get security fixes as if Tomcat 10 didn't exist? 9.10.x, 9.11.x etc will continue to get security fixes. It will be no different from any other supported Tomcat version in that regard. Is there a page on apache.org that explains what you say or are you speaking authoritatively? There have been variations of this on the mailing lists, presented at conferences and on the wiki: https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+Release+Numbering The main variation is whether we start 9.10.x now and and keep 9.Y.x aligned with the latest Tomcat version that supports Jakarta EE or whether we start 9.10.x after 9.0.x is EOL and keep 9.Y.x aligned with the oldest Tomcat version that supports Jakarta EE. Either way, Java EE support will continue. No need for any build process changes if you don't want to. Just use webapps-javaee and the automatic conversion. Well the webapps-javaee dir is good for an existing application that you don't want to touch but maybe there should also be a WEB-INF/lib-javaee/ directory to convert individual jars? That seems like a more likely scenario where people want to use JakartaEE but there are a few libs that haven't made the leap. No need. If you deploy an app with mixed libraries, Tomcat will just convert the ones that need converting. The hard part will be building the app as the IDE won't do the conversion. Probably simpler to use the tool to convert the libraries, deploy them to your local Maven repo and build from there. Ok so the classes don't cascade effortlessly. That doesn't mean you couldn't create a wrapper that just operates on a member. But that means the app can't just code to one API or the other. It has to do the wrapping. If you are prepared to that in the app you would be better to to code to the new API as the search and replace is lot simpler. My point was that a container, like Tomcat, can't - without a lot of plumbing that I'm not 100% is even possible for all use cases - support both Java EE and Jakarta EE concurrently. Ignoring the package change, the biggest difference in Servlet 6 and the other Jakarta EE 10 APIs (Tomcat 10.1.x) is that a lot of the deprecated code has been removed. Just an aside, I must say the community process worries me a little. Say what you want about Oracle but they have provided a stable platform for many years. Contrarily, there have historically been community driven efforts that have produced some, lets say, "extraneous" results. Look into the history of X.500. Or Oasis standards like CORBA. HttpServletRequest.login() is misplaced IMO. When people start designing by committee at conferences, I get a twitch in my eye. It depends a lot on how the committee is run and who is on the committee. There are lots of good examples as well such as the HTTP specs. For the record, HttpServletRequest.login() was defined when Oracle were controlling the Servlet spec. 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. A lot of long standing issues have been resolved for Jakarta EE 10 although for Servlet there are so many such issues only some could be tackled with the time and resources available. Mark - 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?
On Tue, Dec 28, 2021 at 10:52 AM Mark Thomas wrote:
>
> On 28/12/2021 14:58, Michael B Allen wrote:
> > On Tue, Dec 28, 2021 at 3:29 AM Johan Compagner
> > wrote:
> >>
> >> Will that really work?
> >
> > No.
> >
> > Clearly I'm not paying attention because after reading surprisingly
> > little information about this fundamental incompatibility and
> > downloading and trying Tomcat 10, there is no way to use a
> > javax.servlet library or application with a jakarta.servlet app server
> > like Tomcat 10.
>
> Yes there is. Just place the Java EE web application in the
> webapps-javaee directory and Tomcat will convert automatically to
> Jakarta EE and then deploy it.
Hi Mark,
Thanks for the detailed answer.
I will try this (actually I already did but I'm getting 404 so I
probably have some other unrelated problem).
Actually it seems the migration tool behind this feature:
https://github.com/apache/tomcat-jakartaee-migration
is a better and more general solution. If it's just re-writing package
names, can any jar converted using the tomcat-jakartaee-migration tool
be used with another app server like Jetty 11?
> > So now I REALLY want to know if people actually use
> > Tomcat 10 and what the release policy will be going forward for Tomcat
> > 9. Is Tomcat 9 going to be maintained separately with security fixes
> > and such?
>
> It is the intention of the Tomcat community to continue to support
> Tomcat 9 for as long as there are users that want a supported Java EE
> platform.
>
> Normally, we support 3 versions in parallel with a major version
> reaching EOL every ~3 years. Typically a major version will be supported
> for ~10 years.
>
> Tomcat 9 will be different. When Tomcat 9 reaches the normal EOL point
> (roughly 2027) 9.0.x releases will stop but Tomcat 9.10.x releases will
> start. These will essentially track Tomcat 10.x releases but with the
> Java EE API rather than the Jakarta EE API.
>
> When Tomcat 10.x reaches end of life (~2030) 9.10.x releases will stop
> and 9.11.x releases will start. These will essentially track Tomcat 11.x
> releases but with the Java EE API rather than the Jakarta EE API.
>
> And so on for as long as there is community demand for the Java EE
> support and there are 3 Tomcat PMC members willing to vote for the release.
That is encouraging. So just to be crystal clear, Tomcat 9 will get
security fixes as if Tomcat 10 didn't exist?
Is there a page on apache.org that explains what you say or are you
speaking authoritatively?
> If anyone has an app that the conversion tool doesn't handle correctly,
> open a bug, tell us what it isn't getting right and we should be able to
> fix it.
Will do.
> No need for any build process changes if you don't want to. Just use
> webapps-javaee and the automatic conversion.
Well the webapps-javaee dir is good for an existing application that
you don't want to touch but maybe there should also be a
WEB-INF/lib-javaee/ directory to convert individual jars? That seems
like a more likely scenario where people want to use JakartaEE but
there are a few libs that haven't made the leap.
> >package javax.servlet.http;
> >
> >public class HttpServletRequestWrapper extends
> > jakarta.servlet.http.ServletRequestWrapper implements
> > HttpServletRequest
> >{
> > // nothing to see here
> >}
>
> This illustrates the my point. You would not be able to cast an instance
> of javax.servlet.http.HttpServletRequestWrapper to
> javax.servlet.http.ServletRequestWrapper
Ok so the classes don't cascade effortlessly. That doesn't mean you
couldn't create a wrapper that just operates on a member.
> Alternatively, just try and write a class (that compiles) that
> implements javax.servlet.http.HttpServletRequest and
> jakarta.servlet.http.HttpServletRequest
I wasn't suggesting that the javax classes had to actually be jakarta
instances under the hood.
But no matter. If the migration tool actually does what it looks like
it's supposed to do, I would say that's the best option. People can
either call it in their build to make two jars or the operator can use
it to convert a jar at their end.
> Ignoring the package change, the biggest difference in Servlet 6 and the
> other Jakarta EE 10 APIs (Tomcat 10.1.x) is that a lot of the deprecated
> code has been removed.
Just an aside, I must say the community process worries me a little.
Say what you want about Oracle but they have provided a stable
platform for many years. Contrarily, there have historically been
community driven efforts that have produced some, lets say,
"extraneous" results. Look into the history of X.500. Or Oasis
standards like CORBA. HttpServletRequest.login() is misplaced IMO.
When people start designing by committee at conferences, I get a
twitch in my eye.
Mike
--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/
-
To unsubscribe, e-mail:
