Re: Use existing CGI response for HTTP errors
On Fri, Oct 5, 2018 at 3:12 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Daniel,
>
> On 10/3/18 19:16, Daniel Becroft wrote:
> > Hi,
> >
> > We are setting up Tomcat 8 to use a CGI program (.exe, proprietary)
> > to generate and return various JSON responses. This all works fine
> > when the response is a HTTP 200. But, when an HTTP error is
> > returned (HTTP 4xx), Tomcat is generating the HTML page instead.
> >
> > We have the same setup working under IIS, and we had to configure
> > the following option there to stop IIS doing the same thing:
> >
> >
> >
> > Is there an existing option somewhere in Tomcat that will do the
> > same thing (ie keep the CGI response intact even if it's a HTTP
> > error)? I can't seem to find one.
>
> See Mark's response for the "answer" to this; I had another question.
>
> HTTP 4xx responses are usually telling the client that their request
> was bad for some reason, and generally the response entity (the page
> returned) is not relevant.
>
> What kinds of responses are you returning for these errors? Or are you
> trying to make sure that the response is still JSON even if an error
> occurs?
>
> - -chris
>
Thanks Chris.
We are using the response to return information about what was wrong with
the request, and how they might need to fix it.
For example:
{
"errorCode" : "400"
"errorMessages": [ "The customer cannot be terminated with an
outstanding invoice." ]
}
This is the format that our existing consumers are already receiving the
responses in, so we can't change that.
Cheers,
Daniel B.
Re: TC 8.5 cachingAllowed=false ramifications?
On 04/10/18 20:29, Berneburg, Cris J. - US wrote: > RAMBLE: The thing is, it worked in TC 6.0 but not 8.5. Is it possible a > major change in TC threading occurred, so the servlet returns the JSP > response before the Excel file is finished being generated by POI? No, > that's not it - turning off caching fixes the problem. Did TC 6.0 not cache > files? The resources implementation was completely re-written for 8.x in anticipation of a new specification feature that never materialised. Despite that, it needed to be done as there were a number of over-lapping solutions that were very fragile where they overlapped. I'm fairly sure not found results weren't cached in 6.0.x. > GENERAL: Does the fact that a file does *not* exist need to be cached? If a > cache ping fails, checking the file system immediately would make new files > available immediately too, instead of after the cache expires. (Conversely, > how does it handle a file deleted from the file system still existing in the > cache?) Caching not found can improve performance. If a file is deleted, that deletion won't be detected until the associated cache entry expires. > SPECIFIC: The Excel files are dynamic, one-time reports, accessed only once. > They don't need to be cached. Is it possible to declare only the Excel > reports output folder as non-cache-able but leave the (default) context cache > setting as-is so everything else can be cached in the default way? That is, > set up the Excel report output folder as a separate "resource" with an > independent cache setting? Right now the Excel folder is embedded in the app > file system: TC/webapps/app/excel. At the moment, no. No reason why we couldn't extend the resources implementation and either add a few more options (based on path and/or filename and/or mime-type and/or whatever). Where we draw the line between 'standard' options and what requires a custom CacheSelector (ideas for better name welcome) is open to debate. Something for an enhancement request? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat with half open tcp sockets
Sorry, mobile typo. Soap stack, as in cxf, axis, sun jaxws ri On Thu, Oct 4, 2018, 12:57 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Alex, > > On 10/3/18 20:25, Alex O'Ree wrote: > > Thanks Chris. I ended up using aggressive read timeout values on > > the Web service clients by adding properties to the binding > > provider. Thing is, every jre version and soap attacks use > > different versions which made this much harder to track down. > > SOAP attacks? > > FWIW, all clients should always be specifying sane timeout values. > Most programmers are lazy, though, and leave them to the default > (which is almost always "infinite"). > > - -chris > > > On Tue, Oct 2, 2018, 1:44 PM Christopher Schultz < > > ch...@christopherschultz.net> wrote: > > > > Alex, > > > > On 9/29/18 08:31, Alex O'Ree wrote: > Does tomcat detect or mitigate against half open tcp > connections? > > > > Not directly. Basically, that's the OS's job. > > > I recently ran into an issue where something in between a > java jaxws client and a jaxws service running in tomcat is > interfering with the tcp stream. Resolving this client side > has been a challenge due the transmitting thread hanging > forever waiting to read from the remote server and not being > able to be interrupted or aborted. While troubleshooting > this, it dawned on me that services running in tomcat may run > into a similar problem and was wondering if tomcat has any > safe guards for this scenario. If it does, what is the > strategy used? I'm thinking maybe I can something similar > client side. > > > > In these cases, the only option the server has is to close the > > connection and then let the TCP stack purge the connection after > > some time in the penalty box (FIN_WAIT, FIN_WAIT2, or TIME_WAIT). > > > > If you see these kinds of connections piling-up, you may want to > > tweak the options of your TCP stack to have them cleared-out more > > quickly. > > > > -chris > >> > >> - > >> > >> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlu2Rm0ACgkQHPApP6U8 > pFirFxAAwDR7FwEYsLMM8iTy5Kl9dmguVDpJPkXKvw8ar3Djrk7/K1SPVodv7AWV > 2+UqnZvFmDQ9LB9LRKuZc1fqeZsrxltVnJcjSRyIpJQAyWF9D3chNY6h5OYDCi9k > zuoN6naTcGNzmCTLDhoCNsAOO/u4PP24tBXLWqsXGtViuTHXA3DxjHo26PLfcZPT > WrhXyfG8o0eOWZ0vfsCbHzjOeyoVspJl5WIqtT4rszAoZnlUmYsSmjQrmZIJsc0l > TRqHDEZImAbORKiMAt5eTHTnoYN8B6Onp7zhDverCD8vCJS+RabxpXxI/0FH8Y10 > BNKxaNltFfTaqBhWcbcWnO6aKKauLonECjINOEd1Ad0eac0YrkKKBnIIJ6+CTzgh > k1fVF8eev5s1mGydEaI7zUrvXh4iU6kH6E75GIZF1Mk2xbXZRIEXjcQNF4XvxjPz > paQh229ozs0Ul8iyNzRhvr/fuPiVmxrKzXLhEZWDiVcZ946G34a5hfkDv6jSevMr > CnElgmlZ1VwxCzhyiM6EJuoO+pTgj0dOg569xPEhhMtrXyhVtLFFa08IbQFTxLv7 > BYgoQeD8KA8Yxgn0orBBcvP34DAPAw3YZl6FxZ9pxL8X6h+h4fHhqYeHtpMUAqEp > flwUmO8EW/xgHJF58dihGN0sY2lJD8p5XFsWC30i2LJNE+wd2lU= > =K14S > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
RE: TC 8.5 cachingAllowed=false ramifications?
Thanks Mark cjb> Anyone have advice on, experience with, or cjb> info about setting cachingAllowed=false? cjb> [...] cjb> In our testing of TC 8.5.32 on Java 8u181, cjb> report output Excel files won't load cjb> (immediately). An error is displayed to cjb> the user. These Stack Overflow topics cjb> below point to a cachingAllowed setting cjb> [...] cjb> I added cjb> to the in TC/conf/context.xml, cjb> which solved the problem. cjb> 1. What are the ramifications of disabling cjb> the cache? IOW, what are the potential cjb> side-effects? mt> The cache keeps the contents of static files mt> in memory to improve performance. In theory mt> - the more of your requests that can be served mt> from memory, the faster the response time. The mt> side effect is a slower response time. How mt> much actual difference this feature makes will mt> depend on how much static content there is in mt> your app, how frequently it is requested and mt> how frequently it is changed. Yeah, I was thinking something vaguely along those lines. cjb> 2. Is there a "better" way to specify the setting? mt> Maybe. The change you made applied that setting mt> to ALL web applications in that Tomcat instance. mt> If you only wanted to apply it to "/foo" then mt> you would create: mt> $CATALINA_BASE/conf//foo.xml mt> [...] OK, good to know, thanks. cjb> 3. Is there a "better" way to solve the problem? mt> For a given value of "better"... :-) mt> What is happening is that: mt> - "something 1" requests the file mt> - the file is not found and the cache records this mt> - "something 2" creates the file mt> - "something 3" requests the newly created file mt> - the cache is still valid so the not found' response is returned mt> - time passes, 'not found' cache response expires mt> - "something 4" requests the newly created file which is now returned mt> [...] mt> What you'd need to figure out is what is "something 1" mt> and what triggers it before "something 2". With that mt> information, you should be able to refactor the app so mt> "something 1" doesn't happen or happens after "something 2". 1. User client browser sents report request to TC. 2. Servlet does some stuff and calls Apache POI to generate the Excel file. 3. Servlet sends rendered JSP response, which contains HTML and Javascript. 4. Client browser processes response with Javascript, which opens a new window with the URL of the generated Excel file. 5. User client browser sends request for the generated Excel file from the new window. 6. Tomcat returns 404 not found response to new window. 7. User waits 5 to 10 seconds and clicks reload in the browser new window. 8. New client browser window sends request for the generated Excel file to TC. 9. Tomcat returns Excel file to client new window. RAMBLE: The thing is, it worked in TC 6.0 but not 8.5. Is it possible a major change in TC threading occurred, so the servlet returns the JSP response before the Excel file is finished being generated by POI? No, that's not it - turning off caching fixes the problem. Did TC 6.0 not cache files? GENERAL: Does the fact that a file does *not* exist need to be cached? If a cache ping fails, checking the file system immediately would make new files available immediately too, instead of after the cache expires. (Conversely, how does it handle a file deleted from the file system still existing in the cache?) SPECIFIC: The Excel files are dynamic, one-time reports, accessed only once. They don't need to be cached. Is it possible to declare only the Excel reports output folder as non-cache-able but leave the (default) context cache setting as-is so everything else can be cached in the default way? That is, set up the Excel report output folder as a separate "resource" with an independent cache setting? Right now the Excel folder is embedded in the app file system: TC/webapps/app/excel. cjb> a. This is a low-volume application. cjb> Little traffic and few users. cjb> cjb> b. Seeing as we're addressing production, cjb> we would like to implement a rapid solution. cjb> Don't want to refactor the application, cjb> which would take more time. mt> Given the caveats, you solution looks to be the best (assuming performance is acceptable). Thanks Mark. It's reassuring to know the work-around is functional and not unreasonable. -- Cris Berneburg CACI Lead Software Engineer
RE: JasperException in production
Mark cjb> getting the dreaded JasperException in production. cjb> Don't know what changed to start causing this. Same cjb> thing happened in the test environment 9/4/18. We cjb> got around the problem in test by upgrading to Java cjb> 8u181 and Tomcat 8.5.30. cjb> cjb> JRE 8u171, 32 bit cjb> Tomcat 6.0.32, 32 bit cjb> cjb> org.apache.jasper.JasperException: Unable to compile class for JSP: cjb> An error occurred at line: 1 in the generated java file The type cjb> java.io.ObjectInputStream cannot be resolved. It is indirectly cjb> referenced from required .class files cjb> Stacktrace: cjb> at org.apache.jasper.compiler.DefaultErrorHandler.javacError cjb> (DefaultErrorHandler.java:92) cjb> [...] mt> The short version is that there was an upgrade to the mt> Java version which exposed a known 'bug' in the Eclipse mt> compiler. That 'bug' was essentially that the version mt> of Tomcat (and hence the Eclipse compiler) was so old mt> it was not fully compatible with Java 8. OK, thanks for the explanation. cjb> So our current plan is upgrade Tomcat. mt> That should work. Thanks for confirming. You all have been telling me to upgrade for a while. :-) cjb> It should also be possible to fix this by replacing cjb> the ecj.jar in your existing Tomcat 6.0.x installation cjb> with a newer version. Good to know, just in case. Custom tweaks get lost easily, so this will be "Option B". -- Cris Berneburg CACI Lead Software Engineer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Apache failed to initialize connector
Hi Gael >> >> >> On 03/10/18 12:28, Gael REYNOARD wrote: >> >> >>> Hello everybody, >> >> >>> >> >> >>> OS : Windows 7 Pro x64 >> >> >>> Tomcat : 8.5.31 >> >> >>> >> >> >>> On a test bench, I reboot Windows to test one of our C# >> applications. >> >> >>> Sometimes after starting the OS, my Tomcat server fails to >> initialize >> >> >>> because the 8080 or 8009 port would be already used. >> >> >> >> >> >> How are you starting Tomcat? >> >> >> >> >> >> Mark gr> I disabled the automatic start of Tomcat service, gr> it is launched a little later by my program in C #. gr> After 314 startups of the OS, I did not have any exceptions. gr> I did not look well enough on the internet gr> because I found this morning a post gr> (https://stackoverflow.com/questions/51666952/address-bind-exception-in-tomcat) gr> from someone with a similar problem and Microsoft gr> would have provided a solution since july. I have not tried it myself, but have you considered the "Automatic (Delayed Start)" Startup type in your Windows service properties? It's available on my TC service in Windows Server 2012 R2. This Stack Overflow article says it waits 2 minutes: https://stackoverflow.com/questions/11015189/automatic-vs-automatic-delayed-start/11015576#11015576 -- Cris Berneburg, Lead Software Engineer CACI, IRMA Project phone: 703-679-5313 -Original Message- From: Gael REYNOARD Sent: Thursday, October 4, 2018 8:45 AM To: users@tomcat.apache.org Subject: Re: Apache failed to initialize connector Thank you so much, [LARGE SNIP] - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [EXTERNAL] Re: Tomcat custom location for configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Amit, On 10/4/18 12:17, Amit Pande wrote: > Thanks! I will take a detailed relook at using CATALINA_BASE and > keep you posted. > > > Also, since the "-config" option is there since 4.0.x time till > now, would it be safe to assume that this option won't be > deprecated since some users (admittedly not too many) might > actually be using it? If it's going to stay, do you feel it's worth > documenting (till the time it isn't actually deprecated with some > alternate)? > > I agree while not desirable at the moment, using "-config" solves > our problem. So, we might have to use this as last fallback > option. It sounds like this feature barely works and probably doesn't work in many situations. My vote would be to deprecate it immediately and remove it completely in Tomcat 10. I'm sorry, but I don't think I understand why you cannot use CATALINA_BASE as "usual" in your situation. - -chris > On 10/4/18, 8:38 AM, "Mark Thomas" wrote: > > On 03/10/18 17:18, Amit Pande wrote: >> Thank you so much, Mark! >> >> In our case, the server.xml contains some information which is >> generated run time (pre-config before Tomcat is started) like the >> paths to key store and trust store, cipher suites, etc. >> >> Also, we have an active-passive cluster setup in which only the >> currently active node has the access to a shared disk which has >> all our product configuration data including the key store, >> trust store files needed in server.xml. >> >> We have a requirement to share the configuration across both the >> nodes of the cluster to avoid keeping duplicate copies of >> configuration (server.xml). And since some of the server.xml >> configuration is generated runtime, it isn’t trivial in our case >> to keep these copies in sync. >> >> This is the prime reason to have a shared Tomcat configuration. >> We may also want, in future, to spawn and additional instance of >> Tomcat with re-usable configuration (except adjusting the port >> numbers ). >> >> The not-so-elegant choice we might have is to move the entire >> Tomcat installation to this cluster aware shared storage but >> defeats the purpose of having a shared disk for configuration >> data and not the binaries. >> >> What alternates should we explore? > > You could look at using separate CATALINA_HOME and CATALINA_BASE. > See > https://tomcat.apache.org/tomcat-9.0-doc/introduction.html#CATALINA_HO ME_and_CATALINA_BASE > > Whether have the web applications on the node or the shared > storage is arguable either way. If you want it on the node, just > use an absolute path that points to someone on the node for > appBase. > > Mark > > - > > 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 > -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlu2SrwACgkQHPApP6U8 pFjlHw/+OZ8FgsTCHvzIIAYBRdAQ+If0M3Q7Wpp7w/tqUYjbHgERPBiof2arPft5 ir2tfUh11M0YiUvTPXfzzq7BHe5sXsDQHTxLimN1gq6+WOlZVd3k//giFQUmcwsK RZtKUQUnGWUsjJ/n7z4rWna+gdleukWQ0k7qgbRR/dAiaAUd2mRfy4LgKpHvTVex y6SXSmcGZ963vzPuZurMIyfPY2iUxb7Y1dbC8Pv7J0vAWhw1we08t33oMJa3Pcp4 vgV2Ylc6nwyw4LpFcTdNOzWaLIKBwJ4zwv2rQW9Tp8zhiU6O5BfVmzP3Zo04K18x z1Zvw9mhOISIWn0vE+k6WxU/t17UVKYonPUBwJ0JelVNBE/tGsCSwiHK67gBhs0F K/+QN8+625TDcUmxYtTMdXQVel/ZvWCrdVZKCJlM3uHSsSySoPhkQU+gCt9PExx9 YIgxzzViI3NiIkeobf8VmBMtZKaYWLWa6+eSoVVmj8UA7Glj5/tvT8o1AXDerYEk kNWojPCOMx1l6rgysrlX6pRY3ltDnqGmlkzhxrU72afUXMpZ9VhKVawZ5457SEan mYWGR5o09lmUE4VBFt87yL+VVSdmlckrC/2hQjDbK6qHQMUDIM6fs98mJ/fgVE2m pL9gZG/4J3Tp6nQEFuAKehtFO+aQmRk6UKP6iW+ux2iarzQ5Z7k= =32WJ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Use existing CGI response for HTTP errors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Daniel, On 10/3/18 19:16, Daniel Becroft wrote: > Hi, > > We are setting up Tomcat 8 to use a CGI program (.exe, proprietary) > to generate and return various JSON responses. This all works fine > when the response is a HTTP 200. But, when an HTTP error is > returned (HTTP 4xx), Tomcat is generating the HTML page instead. > > We have the same setup working under IIS, and we had to configure > the following option there to stop IIS doing the same thing: > > > > Is there an existing option somewhere in Tomcat that will do the > same thing (ie keep the CGI response intact even if it's a HTTP > error)? I can't seem to find one. See Mark's response for the "answer" to this; I had another question. HTTP 4xx responses are usually telling the client that their request was bad for some reason, and generally the response entity (the page returned) is not relevant. What kinds of responses are you returning for these errors? Or are you trying to make sure that the response is still JSON even if an error occurs? - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlu2SgEACgkQHPApP6U8 pFg9NA/+I2oFYemUtGs2MYJ+UKeB80SPtxdZyxdYdAVOqIa+hdq4cimxq648NGB0 eWalhK7PAn5d24XeUTCSoeKiBcn/CRvGW1E+2qv9tdXZRU7ZQneDWu4vDpm/VK1s Jlv54CdhOr+0BaBY8Gsj/wGncMBpmG0XFNZxJXcGFb63Z9GMsaUxS18dfzC+Lbdc k3Pg2/8s9+dMOwlGYjOZ+uK02Kk2XllCdZhn+rljoImqj1st23fwgdoI4FWho5Pa H9KtWhteYNI6V7F59+5pbl8AyzkWvEyD/AsM2UwXMQBUTyuB0sNj+P5lXGZkDZn5 4eMfpUCbK2m9upquulOYGhtuYwfCqoc9zMIY7eu8mfHKfevmRL9+QBT8iz4QogHw 3F1nMm3wM3uZNInFoRTjfsHTcUdtSKRCAA4G5ocyGSezI4FWU/aWVMz27ZkoUV1e 205YN8+sjk25ihkNDsTZkqXiG3V7IC3Yqh3fiuZQGyL9Zv8GH0dKK9Nu4WTJgjZI saHb+Wsghb3+B9dNMiI4MSrvTnmTUWDT70IX47ArpNH4C23aID9gpIjS72OniAuW Il/a3McqyxR+T2sgaOLN+gY1FbW+XAGPhVQ8TZeywfBB//mdbPGqd24kg3ctEvPm FWGYapZPIcF7i7RE0JaIZH0QH1wmrBqIPiSeKLxEtUA6RJV3Hg8= =OCPo -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC 8.5 cachingAllowed=false ramifications?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Cris, On 10/4/18 09:54, Mark Thomas wrote: > On 04/10/18 14:41, Berneburg, Cris J. - US wrote: >> Hi Folks >> >> Anyone have advice on, experience with, or info about setting >> cachingAllowed=false? >> >> BACKGROUND: >> >> Our customer is suddenly getting a JasperException in production. >> To solve, we're planning to upgrade Tomcat to 8.5.x. In our >> testing of TC 8.5.32 on Java 8u181, report output Excel files >> won't load (immediately). An error is displayed to the user. >> These Stack Overflow topics below point to a cachingAllowed >> setting: >> >> - >> https://stackoverflow.com/questions/44852505/tomcat-8-5-takes-too-lon g-to-recognize-new-content >> >> >> - - https://stackoverflow.com/questions/3743136/how-to-disable-tomcat-cach ing >> >> I added to the in >> TC/conf/context.xml, which solved the problem. >> >> QUESTIONS: >> >> 1. What are the ramifications of disabling the cache? IOW, what >> are the potential side-effects? > > The cache keeps the contents of static files in memory to improve > performance. In theory - the more of your requests that can be > served from memory, the faster the response time. The side effect > is a slower response time. How much actual difference this feature > makes will depend on how much static content there is in your app, > how frequently it is requested and how frequently it is changed. > >> 2. Is there a "better" way to specify the setting? > > Maybe. The change you made applied that setting to ALL web > applications in that Tomcat instance. If you only wanted to apply > it to "/foo" then you would create: > $CATALINA_BASE/conf//foo.xml and add > content something like: /> > >> 3. Is there a "better" way to solve the problem? > > For a given value of "better"... > > What is happening is that: - "something 1" requests the file - the > file is not found and the cache records this - "something 2" > creates the file - "something 3" requests the newly created file - > the cache is still valid so the not found' response is returned - > time passes, 'not found' cache response expires - "something 4" > requests the newly created file which is now returned > > something 1/2/3/4 - may all be different - some may be the same - > may be Tomcat or application code > > What you'd need to figure out is what is "something 1" and what > triggers it before "something 2". With that information, you should > be able to refactor the app so "something 1" doesn't happen or > happens after "something 2". > >> CAVEATS: >> >> a. This is a low-volume application. Little traffic and few >> users. >> >> b. Seeing as we're addressing production, we would like to >> implement a rapid solution. Don't want to refactor the >> application, which would take more time. >> >> THANKS: for your time and assistance! > > Given the caveats, you solution looks to be the best (assuming > performance is acceptable). Long ago, we added something similar to what you are talking about. Basically, it was a file-upload capability for images. We waffled about whether to just map the /uploaded-images/ URL space directly to the disk and have DefaultServlet serve the bytes or to write our own servlet to do the work. We opted to write our own (very basic) servlet to do the work because of our concerns over caching by DefaultServlet / Resources. If you want complete control, you have to take responsibility for that complete control. Re-reading the documentation for (specifically, ), it seems that: ... might do the trick, and it would only disable caching for that portion of the disk. Perhaps this would be a better solution, because it only disabled caching for a *portion* of the requests you'll be handling. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlu2SX0ACgkQHPApP6U8 pFiQlxAAvUP050ASoS/ZbFuEH2bY0On7RozGAZIThJUBlxKVFYOcIeKC6Vz9jB0d IUhBhA4CwXI3Pq908LDkmsV4qtvxwEGb0jhjYc31JThyBWy9Ps9RsPhApFHvt1fR Prdm5/y5PQsi1sU8bYvyA3TIgkgeX5Wh+x/XNh502eR6Y7MaIwrp58u4FzPW9BXx 0/ByD5UCnnpYm7Rhc6+aFB3YzgVrWx04DKgJCp+McjsPpUwVuPsXSG1pqe7Yjp7M EHVRDKmhlB/+UHNPJ+XC8mcFCf0giEFh7k1m9m0jMtCx2hzIe2mt5HYTWi92QtRD Qvko3s/dqtSzqUt2JZoFvG2pyabqsnGNWZmsLQfcHMJXgwRCirRz2rManlHX/qAe 0mbwUc/0wJKyV2P7vcgO9X7tBzqgqIuTbsa11+Qo9xos3/Oi3hDlmo5CdbJ3tX/l QboQnR+5nx2FAkSVfdFblR3eUGBUl8GTX055h0m1KtAw9cOCfaIvyK0Vo681Pahr +4a74tfOH+e+oU7x7pYD+2/7O7d9/1dz4NiCUQNYlMvoLTZJY1A9eDFoxSYajG4Y GfkCJD5kJAiE70lZ7J2rRJLQiA+o+OSjGdHmikYqD00IoK0jJv9nMuNOfDe9FRy7 Q2vAm1yzzkMaZcQPRBFs9RDFw4VtL47j8OpWmFeNdNah2dH4rlg= =QTsR -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat with half open tcp sockets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Alex, On 10/3/18 20:25, Alex O'Ree wrote: > Thanks Chris. I ended up using aggressive read timeout values on > the Web service clients by adding properties to the binding > provider. Thing is, every jre version and soap attacks use > different versions which made this much harder to track down. SOAP attacks? FWIW, all clients should always be specifying sane timeout values. Most programmers are lazy, though, and leave them to the default (which is almost always "infinite"). - -chris > On Tue, Oct 2, 2018, 1:44 PM Christopher Schultz < > ch...@christopherschultz.net> wrote: > > Alex, > > On 9/29/18 08:31, Alex O'Ree wrote: Does tomcat detect or mitigate against half open tcp connections? > > Not directly. Basically, that's the OS's job. > I recently ran into an issue where something in between a java jaxws client and a jaxws service running in tomcat is interfering with the tcp stream. Resolving this client side has been a challenge due the transmitting thread hanging forever waiting to read from the remote server and not being able to be interrupted or aborted. While troubleshooting this, it dawned on me that services running in tomcat may run into a similar problem and was wondering if tomcat has any safe guards for this scenario. If it does, what is the strategy used? I'm thinking maybe I can something similar client side. > > In these cases, the only option the server has is to close the > connection and then let the TCP stack purge the connection after > some time in the penalty box (FIN_WAIT, FIN_WAIT2, or TIME_WAIT). > > If you see these kinds of connections piling-up, you may want to > tweak the options of your TCP stack to have them cleared-out more > quickly. > > -chris >> >> - >> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlu2Rm0ACgkQHPApP6U8 pFirFxAAwDR7FwEYsLMM8iTy5Kl9dmguVDpJPkXKvw8ar3Djrk7/K1SPVodv7AWV 2+UqnZvFmDQ9LB9LRKuZc1fqeZsrxltVnJcjSRyIpJQAyWF9D3chNY6h5OYDCi9k zuoN6naTcGNzmCTLDhoCNsAOO/u4PP24tBXLWqsXGtViuTHXA3DxjHo26PLfcZPT WrhXyfG8o0eOWZ0vfsCbHzjOeyoVspJl5WIqtT4rszAoZnlUmYsSmjQrmZIJsc0l TRqHDEZImAbORKiMAt5eTHTnoYN8B6Onp7zhDverCD8vCJS+RabxpXxI/0FH8Y10 BNKxaNltFfTaqBhWcbcWnO6aKKauLonECjINOEd1Ad0eac0YrkKKBnIIJ6+CTzgh k1fVF8eev5s1mGydEaI7zUrvXh4iU6kH6E75GIZF1Mk2xbXZRIEXjcQNF4XvxjPz paQh229ozs0Ul8iyNzRhvr/fuPiVmxrKzXLhEZWDiVcZ946G34a5hfkDv6jSevMr CnElgmlZ1VwxCzhyiM6EJuoO+pTgj0dOg569xPEhhMtrXyhVtLFFa08IbQFTxLv7 BYgoQeD8KA8Yxgn0orBBcvP34DAPAw3YZl6FxZ9pxL8X6h+h4fHhqYeHtpMUAqEp flwUmO8EW/xgHJF58dihGN0sY2lJD8p5XFsWC30i2LJNE+wd2lU= =K14S -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [EXTERNAL] Re: Tomcat custom location for configuration
Thanks! I will take a detailed relook at using CATALINA_BASE and keep you posted. Also, since the "-config" option is there since 4.0.x time till now, would it be safe to assume that this option won't be deprecated since some users (admittedly not too many) might actually be using it? If it's going to stay, do you feel it's worth documenting (till the time it isn't actually deprecated with some alternate)? I agree while not desirable at the moment, using "-config" solves our problem. So, we might have to use this as last fallback option. Thanks, Amit On 10/4/18, 8:38 AM, "Mark Thomas" wrote: On 03/10/18 17:18, Amit Pande wrote: > Thank you so much, Mark! > > In our case, the server.xml contains some information which is generated run time (pre-config before Tomcat is started) like the paths to key store and trust store, cipher suites, etc. > > Also, we have an active-passive cluster setup in which only the currently active node has the access to a shared disk which has all our product configuration data including the key store, trust store files needed in server.xml. > > We have a requirement to share the configuration across both the nodes of the cluster to avoid keeping duplicate copies of configuration (server.xml). And since some of the server.xml configuration is generated runtime, it isn’t trivial in our case to keep these copies in sync. > > This is the prime reason to have a shared Tomcat configuration. We may also want, in future, to spawn and additional instance of Tomcat with re-usable configuration (except adjusting the port numbers ). > > The not-so-elegant choice we might have is to move the entire Tomcat installation to this cluster aware shared storage but defeats the purpose of having a shared disk for configuration data and not the binaries. > > What alternates should we explore? You could look at using separate CATALINA_HOME and CATALINA_BASE. See https://tomcat.apache.org/tomcat-9.0-doc/introduction.html#CATALINA_HOME_and_CATALINA_BASE Whether have the web applications on the node or the shared storage is arguable either way. If you want it on the node, just use an absolute path that points to someone on the node for appBase. Mark - 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: StuckThreadDetectionValve with threads on IO
On 04/10/18 01:08, Behrooz Nobakht wrote: > [1] uses a time based threshold to mark a request thread as "stuck" above > the configured threshold. > > This is definitely useful, but maybe a thread is busy transferring a large > request (IO). This could become > a wrong conclusion for the thread to be marked as stuck. > > A relevant contextual example is that nginx has proxy_read_timeout [2] > (although Tomcat is not by definition a proxy) > The above checks if the server is transmitting any bytes over the wire > (socket read timeout) to decide if a request is stuck or not. > > I am wondering if there's a similar way to achieve the same in Tomcat > (possibly without using NIO connectors)? It should be possible with a custom Valve. It would need to be along similar lines to the StuckThreadDetectionValve but record more information. Namely the response object and the last value of response.getBytesWritten(false). The idea is that on each cycle of the background process, you'd check the current value of response.getBytesWritten(false) and compare it to the last. HTH, Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Use existing CGI response for HTTP errors
On 04/10/18 00:16, Daniel Becroft wrote:
> Hi,
>
> We are setting up Tomcat 8 to use a CGI program (.exe, proprietary) to
> generate and return various JSON responses. This all works fine when the
> response is a HTTP 200. But, when an HTTP error is returned (HTTP 4xx),
> Tomcat is generating the HTML page instead.
>
> We have the same setup working under IIS, and we had to configure the
> following option there to stop IIS doing the same thing:
>
>
>
> Is there an existing option somewhere in Tomcat that will do the same thing
> (ie keep the CGI response intact even if it's a HTTP error)? I can't seem
> to find one.
No, but I think you can work-around it. If the response has been
committed (i.e. written to the network), Tomcat can't replace the error
page. Try adding a filter that calls ServletResponse.flushBuffer()
immediately after the CGI servlet has finished.
Something like (untested):
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain)
throws IOException, ServletException {
chain.doFilter(request,response);
response.flushBuffer();
}
> ---
> Daniel Becroft
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC 8.5 cachingAllowed=false ramifications?
On 04/10/18 14:41, Berneburg, Cris J. - US wrote: > Hi Folks > > Anyone have advice on, experience with, or info about setting > cachingAllowed=false? > > BACKGROUND: > > Our customer is suddenly getting a JasperException in production. To solve, > we're planning to upgrade Tomcat to 8.5.x. In our testing of TC 8.5.32 on > Java 8u181, report output Excel files won't load (immediately). An error is > displayed to the user. These Stack Overflow topics below point to a > cachingAllowed setting: > > - > https://stackoverflow.com/questions/44852505/tomcat-8-5-takes-too-long-to-recognize-new-content > > - https://stackoverflow.com/questions/3743136/how-to-disable-tomcat-caching > > I added to the in > TC/conf/context.xml, which solved the problem. > > QUESTIONS: > > 1. What are the ramifications of disabling the cache? IOW, what are the > potential side-effects? The cache keeps the contents of static files in memory to improve performance. In theory - the more of your requests that can be served from memory, the faster the response time. The side effect is a slower response time. How much actual difference this feature makes will depend on how much static content there is in your app, how frequently it is requested and how frequently it is changed. > 2. Is there a "better" way to specify the setting? Maybe. The change you made applied that setting to ALL web applications in that Tomcat instance. If you only wanted to apply it to "/foo" then you would create: $CATALINA_BASE/conf//foo.xml and add content something like: > 3. Is there a "better" way to solve the problem? For a given value of "better"... What is happening is that: - "something 1" requests the file - the file is not found and the cache records this - "something 2" creates the file - "something 3" requests the newly created file - the cache is still valid so the not found' response is returned - time passes, 'not found' cache response expires - "something 4" requests the newly created file which is now returned something 1/2/3/4 - may all be different - some may be the same - may be Tomcat or application code What you'd need to figure out is what is "something 1" and what triggers it before "something 2". With that information, you should be able to refactor the app so "something 1" doesn't happen or happens after "something 2". > CAVEATS: > > a. This is a low-volume application. Little traffic and few users. > > b. Seeing as we're addressing production, we would like to implement a rapid > solution. Don't want to refactor the application, which would take more time. > > THANKS: for your time and assistance! Given the caveats, you solution looks to be the best (assuming performance is acceptable). Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
TC 8.5 cachingAllowed=false ramifications?
Hi Folks Anyone have advice on, experience with, or info about setting cachingAllowed=false? BACKGROUND: Our customer is suddenly getting a JasperException in production. To solve, we're planning to upgrade Tomcat to 8.5.x. In our testing of TC 8.5.32 on Java 8u181, report output Excel files won't load (immediately). An error is displayed to the user. These Stack Overflow topics below point to a cachingAllowed setting: - https://stackoverflow.com/questions/44852505/tomcat-8-5-takes-too-long-to-recognize-new-content - https://stackoverflow.com/questions/3743136/how-to-disable-tomcat-caching I added to the in TC/conf/context.xml, which solved the problem. QUESTIONS: 1. What are the ramifications of disabling the cache? IOW, what are the potential side-effects? 2. Is there a "better" way to specify the setting? 3. Is there a "better" way to solve the problem? CAVEATS: a. This is a low-volume application. Little traffic and few users. b. Seeing as we're addressing production, we would like to implement a rapid solution. Don't want to refactor the application, which would take more time. THANKS: for your time and assistance! -- Cris Berneburg CACI Lead Software Engineer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [EXTERNAL] Re: Tomcat custom location for configuration
On 03/10/18 17:18, Amit Pande wrote: > Thank you so much, Mark! > > In our case, the server.xml contains some information which is generated run > time (pre-config before Tomcat is started) like the paths to key store and > trust store, cipher suites, etc. > > Also, we have an active-passive cluster setup in which only the currently > active node has the access to a shared disk which has all our product > configuration data including the key store, trust store files needed in > server.xml. > > We have a requirement to share the configuration across both the nodes of the > cluster to avoid keeping duplicate copies of configuration (server.xml). And > since some of the server.xml configuration is generated runtime, it isn’t > trivial in our case to keep these copies in sync. > > This is the prime reason to have a shared Tomcat configuration. We may also > want, in future, to spawn and additional instance of Tomcat with re-usable > configuration (except adjusting the port numbers ). > > The not-so-elegant choice we might have is to move the entire Tomcat > installation to this cluster aware shared storage but defeats the purpose of > having a shared disk for configuration data and not the binaries. > > What alternates should we explore? You could look at using separate CATALINA_HOME and CATALINA_BASE. See https://tomcat.apache.org/tomcat-9.0-doc/introduction.html#CATALINA_HOME_and_CATALINA_BASE Whether have the web applications on the node or the shared storage is arguable either way. If you want it on the node, just use an absolute path that points to someone on the node for appBase. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JasperException in production
On 04/10/18 14:21, Berneburg, Cris J. - US wrote: > OK, now we're getting the dreaded JasperException in production. Don't know > what changed to start causing this. Same thing happened in the test > environment 9/4/18. We got around the problem in test by upgrading to Java > 8u181 and Tomcat 8.5.30. > > JRE 8u171, 32 bit > Tomcat 6.0.32, 32 bit > > org.apache.jasper.JasperException: Unable to compile class for JSP: > An error occurred at line: 1 in the generated java file > The type java.io.ObjectInputStream cannot be resolved. It is indirectly > referenced from required .class files > Stacktrace: > at > org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:92) > [...] Googling for: "The type java.io.ObjectInputStream cannot be resolved. It is indirectly referenced from required .class files" returned a number of similar explanations: https://bugs.openjdk.java.net/browse/JDK-8155223 https://bugzilla.redhat.com/show_bug.cgi?id=1337940 The second of those is probably the clearest. The short version is that there was an upgrade to the Java version which exposed a known 'bug' in the Eclipse compiler. That 'bug' was essentially that the version of Tomcat (and hence the Eclipse compiler) was so old it was not fully compatible with Java 8. > So our current plan is upgrade Tomcat. That should work. It should also be possible to fix this by replacing the ecj.jar in your existing Tomcat 6.0.x installation with a newer version. > Another message to follow about TC 8.5 compatibility problems, specifically > cachingAllowed. ACK. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Customizable parallel deployment
On 04/10/18 13:24, Tomáš Bleša wrote: > As I understand tomcat documentation, parallel deployment is intended to be > used to smoothly rollout new versions of webapp. I've looked in source code > and it's written such that there is probably no way to custimize selection of > proper context version. If session is invalid then newest version is always > selected. > I wonder if it would be desirable to build in more flexibility in context > selection process. For example consider following scenario (real one in my > company). We develop complex CRM system and one ROOT.war is used by multiple > customers. Each customer has special ID that has to be part of URL address: > > site.com?customer=A > site.com?customer=B > ... > All customers A, B, C, ... use the same version 5.x of our app. Now we have > version 6 with massive changes in UI (+external API) and we want to gradually > move our customer base (with their consent) from version 5 to version 6. We > cannot afford to migrate all customers to v6 at once. Giving each of our > customers unique URL (a.site.com, b.site.com, ...) and use virtual hosting is > technically possible but it would complicate other things in our > infrastructure. > > What I would like to accomplish is to have multiple versions of the app, e.g.: > ROOT##571.war > ROOT##572.war // hotfix of 5.7.1 > ROOT##573.war // hotfix of 5.7.2 > ROOT##600.war > ROOT##601.war // hotfix of 6.0.0 > > and two-step process of context version selection. > Step 1) > Belong the request to customer with version 5? -> pre-select ##571, > ##572, ##573 > Belong the request to customer with version 6? -> pre-select ##600, > ##601 > Done by my custom ContextVersionSelector interface implementation > (which of coarse would check "customer" param in URI) > Step 2) > Use StandardContextVersionSelector on results from previous step > (current behavior ... it would be used always as last applied selector) > > If I understand the code right, all context selection magic is done in > Mapper.java (which is now declared final) and it would have to be modified to > support customizable version selection. > > My questions are: > Is there a better way how to accomplish "slow pace" rollout of new version? > (I mean with just Tomcat and nothing more) Having multiple virtual hosts / tomcat instances is the usual way of handling this but you have ruled that out. It could be done fairly simply if you inserted a reverse proxy in front of Tomcat but that breaks your 'just Tomcat' requirement. > If not, do you consider my proposed Mapper imrovement interesting/useful? (I > can try pull request) This looks to be a fairly specific use case. Given that: - the use case is specific - the changes are likely to be quite invasive - the changes would be to code that executes for every request I suspect that there would be some resistance to these changes being included in a standard Tomcat distribution. What I think is much more likely is changes to visibility and/or refactoring to make the context version selection pluggable so you (or anyone else) can easily insert your own implementation. If you proposed changes like that in a PR then I think they are much more likely to be accepted. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
JasperException in production
OK, now we're getting the dreaded JasperException in production. Don't know what changed to start causing this. Same thing happened in the test environment 9/4/18. We got around the problem in test by upgrading to Java 8u181 and Tomcat 8.5.30. JRE 8u171, 32 bit Tomcat 6.0.32, 32 bit org.apache.jasper.JasperException: Unable to compile class for JSP: An error occurred at line: 1 in the generated java file The type java.io.ObjectInputStream cannot be resolved. It is indirectly referenced from required .class files Stacktrace: at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:92) [...] So our current plan is upgrade Tomcat. Another message to follow about TC 8.5 compatibility problems, specifically cachingAllowed. -- Cris Berneburg CACI Lead Software Engineer
Re: Apache failed to initialize connector
Thank you so much, I disabled the automatic start of Tomcat service, it is launched a little later by my program in C #. After 314 startups of the OS, I did not have any exceptions. I did not look well enough on the internet because I found this morning a post ( https://stackoverflow.com/questions/51666952/address-bind-exception-in-tomcat) from someone with a similar problem and Microsoft would have provided a solution since july. My test bench is no longer on the internet for a while, it is not currently up to date. I will also check this solution by performing a Windows Update of my PC. Sorry for the inconvenience and thanks again for your help. Best regards, -- * Gaël REYNOARD* - Ingénieur Recherche & Développement Service *Bureau d'étude informatique* 44 avenue Victor Meunier - 33530 BASSENS Fixe 05.57.80.80.80 - Fax 05.56.31.61.21 - Poste interne 100 235 gael.reyno...@lafon.fr - www.lafon.fr Le mer. 3 oct. 2018 à 17:20, Gael REYNOARD a écrit : > Thank you for that answer > The Windows firewall is disabled on my machine, but I will try this method > and I will come back to you if it corrects my problem. > > Best regards, > -- > * Gaël REYNOARD* - Ingénieur Recherche & Développement > Service *Bureau d'étude informatique* > 44 avenue Victor Meunier - 33530 BASSENS > Fixe 05.57.80.80.80 - Fax 05.56.31.61.21 - Poste interne 100 235 > gael.reyno...@lafon.fr - www.lafon.fr > > > Le mer. 3 oct. 2018 à 17:06, M. Manna a écrit : > >> it looks like you've bound your port 8009 and 8080 with something else >> temporarily during windows startup.It may be some port scanning service or >> some firewall/ prevention service is blocking all the ports until some >> checks are done. And that is why you have this issue intermittently. >> >> As a verification, you can disable auto startup of tomcat service upon >> window start. Upon startup, you can start tomcat manually (repeat it 2-3 >> times) to confirm that there is no problem. >> >> >> On Wed, 3 Oct 2018 at 15:57, Gael REYNOARD >> wrote: >> >> > Sorry for my previous answer, I did not give enough details. >> > >> > So, yes Tomcat start automatically when the OS starts and I only >> installed >> > one instance of the Tomcat service. >> > >> > I thought about this idea of the service that starts twice, but I did >> not >> > see anything in the log (commons-daemon.2018-10-02.log) that would >> indicate >> > several start of the service. >> > >> > I just checked the Windows events and I only have one Tomcat service run >> > every time Windows starts. >> > This problem does not seem to happen very often because with 102 Windows >> > starts I only had the problem 3 times. >> > >> > Best regards, >> > -- >> > * Gaël REYNOARD* - Ingénieur Recherche & Développement >> > Service *Bureau d'étude informatique* >> > 44 avenue Victor Meunier - 33530 BASSENS >> > Fixe 05.57.80.80.80 - Fax 05.56.31.61.21 - Poste interne 100 235 >> > gael.reyno...@lafon.fr - www.lafon.fr >> > >> > >> > Le mer. 3 oct. 2018 à 16:17, Mark Thomas a écrit : >> > >> >> On 03/10/18 14:54, Gael REYNOARD wrote: >> >> > Tomcat is installed as a service in Windows with a dependency with >> the >> >> SQL >> >> > Server service. >> >> > >> >> > I can also add when I have this problem, if I manually restart the >> >> Tomcat8 >> >> > service, it restarts correctly. >> >> >> >> How are you *starting* Tomcat? Manually starting the service? >> >> Automatically when the OS starts? >> >> >> >> Also, what are the contents of the service wrapper logs? >> >> >> >> It looks like the service is being started twice and failing (as >> >> expected) the second time. Or you have two Tomcat services trying to >> use >> >> the same ports. Or ... >> >> >> >> Mark >> >> >> >> >> >> > >> >> > Best regards, >> >> > -- >> >> > * Gaël REYNOARD* - Ingénieur Recherche & Développement >> >> > Service *Bureau d'étude informatique* >> >> > 44 avenue Victor Meunier - 33530 BASSENS >> >> > Fixe 05.57.80.80.80 - Fax 05.56.31.61.21 - Poste interne 100 235 >> >> > gael.reyno...@lafon.fr - www.lafon.fr >> >> > >> >> > >> >> > Le mer. 3 oct. 2018 à 15:40, Mark Thomas a écrit >> : >> >> > >> >> >> On 03/10/18 12:28, Gael REYNOARD wrote: >> >> >>> Hello everybody, >> >> >>> >> >> >>> OS : Windows 7 Pro x64 >> >> >>> Tomcat : 8.5.31 >> >> >>> >> >> >>> On a test bench, I reboot Windows to test one of our C# >> applications. >> >> >>> Sometimes after starting the OS, my Tomcat server fails to >> initialize >> >> >>> because the 8080 or 8009 port would be already used. >> >> >> >> >> >> How are you starting Tomcat? >> >> >> >> >> >> Mark >> >> >> >> >> >> >> >> >>> I changed the default port 8080 by and I had the same error >> after >> >> >>> several reboots of my OS. >> >> >>> >> >> >>> I check with the NETSTAT -atonb -p TCP command and I have Tomcat >> that >> >> is >> >> >>> listening to p
Customizable parallel deployment
As I understand tomcat documentation, parallel deployment is intended to be used to smoothly rollout new versions of webapp. I've looked in source code and it's written such that there is probably no way to custimize selection of proper context version. If session is invalid then newest version is always selected. I wonder if it would be desirable to build in more flexibility in context selection process. For example consider following scenario (real one in my company). We develop complex CRM system and one ROOT.war is used by multiple customers. Each customer has special ID that has to be part of URL address: site.com?customer=A site.com?customer=B ... All customers A, B, C, ... use the same version 5.x of our app. Now we have version 6 with massive changes in UI (+external API) and we want to gradually move our customer base (with their consent) from version 5 to version 6. We cannot afford to migrate all customers to v6 at once. Giving each of our customers unique URL (a.site.com, b.site.com, ...) and use virtual hosting is technically possible but it would complicate other things in our infrastructure. What I would like to accomplish is to have multiple versions of the app, e.g.: ROOT##571.war ROOT##572.war // hotfix of 5.7.1 ROOT##573.war // hotfix of 5.7.2 ROOT##600.war ROOT##601.war // hotfix of 6.0.0 and two-step process of context version selection. Step 1) Belong the request to customer with version 5? -> pre-select ##571, ##572, ##573 Belong the request to customer with version 6? -> pre-select ##600, ##601 Done by my custom ContextVersionSelector interface implementation (which of coarse would check "customer" param in URI) Step 2) Use StandardContextVersionSelector on results from previous step (current behavior ... it would be used always as last applied selector) If I understand the code right, all context selection magic is done in Mapper.java (which is now declared final) and it would have to be modified to support customizable version selection. My questions are: Is there a better way how to accomplish "slow pace" rollout of new version? (I mean with just Tomcat and nothing more) If not, do you consider my proposed Mapper imrovement interesting/useful? (I can try pull request) Thanks Tomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Load Balancing to Tomcat Workers
Thanks very much Rainer . I will check deeply what you said . Thanks again Sent from my Samsung Galaxy smartphone. Original message From: Rainer Jung Date: 10/4/18 10:35 AM (GMT+02:00) To: Tomcat Users List Subject: Re: Load Balancing to Tomcat Workers Just adding a bit below ... Am 03.10.2018 um 22:40 schrieb Christopher Schultz: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Loai, > > On 10/3/18 16:07, Loai Abdallatif wrote: >> Hello, >> >> I have configures web server with jk load balancer to tomcat >> server (192.168.237.11) with two containers worker 0, worker1) the >> problem is that the web application session seems keep rotating >> between both workers but I need session stickeness, means the >> client will be connected to the same worker which doesn't occur , > > Sticky sessions are the default. > >> the workers.properties file has this content : >> worker.list=EVOUCHER_LB, jk-status, jk-manager, EVOUCHER_LB # >> Define worker0 -- appserver1 worker.worker_app1.type=ajp13 >> worker.worker_app1.host=192.168.237.11 >> worker.worker_app1.port=8009 >> worker.worker_app1.socket_timeout=1200 >> worker.worker_app1.connection_pool_size=1 >> worker.worker_app1.connection_pool_timeout=1300 >> worker.worker_app1.lbfactor=1 >> worker.worker_app1.redirect=worker_app2 >> worker.worker_app1.sticky_session=1 > > You haven't specified a route name. Is the jvmRoute for your > 192.168.237.11 set to "worker_app1"? If not, you'll have to set > worker.worker_app1.route=routeName and do the same in your > for your jvmRoute attribute. > >> # >> #Define worker1 -- appserver1 worker.worker_app2.type=ajp13 >> worker.worker_app2.host=192.168.237.11 >> worker.worker_app2.port=8109 >> worker.worker_app2.socket_timeout=1200 >> worker.worker_app2.connection_pool_size=1 >> worker.worker_app2.connection_pool_timeout=1300 >> worker.worker_app2.lbfactor=1 >> worker.worker_app2.redirect=worker_app1 >> worker.worker_app2.sticky_session=1 > > Same here. > > Read the workers.properties documentation[1] for these settings just > to make sure you understand everything before you start changing > things. Specifically, read the introduction to the "Load Balancing > Directives" section (which specifically, in RED TEXT, warns you about > setting these parameters and making sure they agree). Read about the > "route" attribute and also read about "redirect" (which shouldn't be > necessary unless there is a specific reason to fail-over to one worker > specifically, as opposed to one in particular). The only use-case I > can think of for "redirect" is when you are using the BackupManager > for session-clustering. I don't see a balancer worker defined (type lb) and configured. Some of the attributes you set belong to a balancer worker. I suggest reading http://tomcat.apache.org/connectors-doc/common_howto/loadbalancers.html The point about setting jvmRoute in your Tomcat's server.xml is very important. A good starting point for a mod_jk config is here: http://svn.apache.org/viewvc/tomcat/jk/trunk/conf/ The files are also contained in the source release of mod_jk available under https://tomcat.apache.org/download-connectors.cgi Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Load Balancing to Tomcat Workers
Just adding a bit below ... Am 03.10.2018 um 22:40 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Loai, On 10/3/18 16:07, Loai Abdallatif wrote: Hello, I have configures web server with jk load balancer to tomcat server (192.168.237.11) with two containers worker 0, worker1) the problem is that the web application session seems keep rotating between both workers but I need session stickeness, means the client will be connected to the same worker which doesn't occur , Sticky sessions are the default. the workers.properties file has this content : worker.list=EVOUCHER_LB, jk-status, jk-manager, EVOUCHER_LB # Define worker0 -- appserver1 worker.worker_app1.type=ajp13 worker.worker_app1.host=192.168.237.11 worker.worker_app1.port=8009 worker.worker_app1.socket_timeout=1200 worker.worker_app1.connection_pool_size=1 worker.worker_app1.connection_pool_timeout=1300 worker.worker_app1.lbfactor=1 worker.worker_app1.redirect=worker_app2 worker.worker_app1.sticky_session=1 You haven't specified a route name. Is the jvmRoute for your 192.168.237.11 set to "worker_app1"? If not, you'll have to set worker.worker_app1.route=routeName and do the same in your for your jvmRoute attribute. # #Define worker1 -- appserver1 worker.worker_app2.type=ajp13 worker.worker_app2.host=192.168.237.11 worker.worker_app2.port=8109 worker.worker_app2.socket_timeout=1200 worker.worker_app2.connection_pool_size=1 worker.worker_app2.connection_pool_timeout=1300 worker.worker_app2.lbfactor=1 worker.worker_app2.redirect=worker_app1 worker.worker_app2.sticky_session=1 Same here. Read the workers.properties documentation[1] for these settings just to make sure you understand everything before you start changing things. Specifically, read the introduction to the "Load Balancing Directives" section (which specifically, in RED TEXT, warns you about setting these parameters and making sure they agree). Read about the "route" attribute and also read about "redirect" (which shouldn't be necessary unless there is a specific reason to fail-over to one worker specifically, as opposed to one in particular). The only use-case I can think of for "redirect" is when you are using the BackupManager for session-clustering. I don't see a balancer worker defined (type lb) and configured. Some of the attributes you set belong to a balancer worker. I suggest reading http://tomcat.apache.org/connectors-doc/common_howto/loadbalancers.html The point about setting jvmRoute in your Tomcat's server.xml is very important. A good starting point for a mod_jk config is here: http://svn.apache.org/viewvc/tomcat/jk/trunk/conf/ The files are also contained in the source release of mod_jk available under https://tomcat.apache.org/download-connectors.cgi Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
