Tracking down a Basic.sendBinary() issue

[Robert Lewis]

Hi,

I am tracking down a fairly sporadic bug in our software that uses Tomcat
8.0.38. Long story short, sometimes calls to Basic.sendBinary() to a full
buffer then to a small buffer (eg. 8192x3 then 444 bytes). The first 8192
sends will succeed and occasionally we see the last 444 byte send 'fail' in
a way that we never see it leave the network, resulting in the client
waiting for bytes and eventually timing out. We notice that if we close the
the connection remotely, the bytes immediately get sent.

This led me to believe something was not getting flushed properly. This URL
indicates that there were some recent conversations about something similar:

http://tomcat.10.x6.nabble.com/Tomcat-WebSocket-does-not-
always-send-asynchronous-messages-td5060965.html

I decided to dig further and tried to send a ping between sending bytes, it
seems to alleviate the problem, but still doesn't tell me what is going on.
Taking a suggestion from Mark T.  \around a 'possible race condition in the
web socket code', I debugged through tomcat code looking for race
conditions, and immediately a source file and function (doWrite()) stood
out, it is modifying state then calling to another public function to act
on that state:

https://github.com/apache/tomcat/blob/TOMCAT_8_0_0_RC10/
java/org/apache/tomcat/websocket/server/WsRemoteEndpointImplServer.java

Further up, the doWrite() caller in the endpoint was moved out of a sync
block to prevent a deadlock (there was a specific comment around this),
which leads me to believe that something was calling doWrite() on multiple
threads, but I have not tracked that down yet.

Anyway, there was a recent code change on the 8.5.x series to the doWrite()
implementation which checks to see if it is a blocking call, then sends
immediately to the socket and flushes without class level state. I have not
tested this yet to see if it solves the issue as we are tied to 8.0.x for
now, but working on migrating our code to work with 8.5.x.

Most of the work on the files seem to be done by Mark T. (awesome work, we
rely on this functionality heavily!) so I figured I would reach out and ask
about the doWrite() change to have a else block for blocking sockets. Is
this intended to fix the issue I am describing above?

I would check the history but I cannot seem to find the source for the
initial commit that introduces the else block for 8.5.x.

Thanks,
  -Rob

Tracking down a Basic.sendBinary() issue

[Robert Lewis]

Hi,

I am tracking down a fairly sporadic bug in our software that uses Tomcat
8.0.38. Long story short, sometimes calls to Basic.sendBinary() to a full
buffer then to a small buffer (eg. 8192x3 then 444 bytes). The first 8192
sends will succeed and occasionally we see the last 444 byte send 'fail' in
a way that we never see it leave the network, resulting in the client
waiting for bytes and eventually timing out. We notice that if we close the
the connection remotely, the bytes immediately get sent.

This led me to believe something was not getting flushed properly. This URL
indicates that there were some recent conversations about something similar:

http://tomcat.10.x6.nabble.com/Tomcat-WebSocket-does-not-alw
ays-send-asynchronous-messages-td5060965.html

I decided to dig further and tried to send a ping between sending bytes, it
seems to alleviate the problem, but still doesn't tell me what is going on.
Taking a suggestion from Mark T.  \around a 'possible race condition in the
web socket code', I debugged through tomcat code looking for race
conditions, and immediately a source file and function (doWrite()) stood
out, it is modifying state then calling to another public function to act
on that state:

https://github.com/apache/tomcat/blob/TOMCAT_8_0_0_RC10/java
/org/apache/tomcat/websocket/server/WsRemoteEndpointImplServer.java

Further up the call stack, the doWrite() caller in the endpoint was moved
out of a sync block to prevent a deadlock (there was a specific comment
around this), which leads me to believe that something was calling
doWrite() on multiple threads, but I have not tracked that down yet.

Anyway, there was a recent code change on the 8.5.x series to the doWrite()
implementation which checks to see if it is a blocking call, then sends
immediately to the socket and flushes without class level state. I have not
tested this yet to see if it solves the issue as we are tied to 8.0.x for
now, but working on migrating our code to work with 8.5.x. Change for added
else here:
https://github.com/apache/tomcat/blob/TOMCAT_9_0_0_M19/java/org/apache/tomcat/websocket/server/WsRemoteEndpointImplServer.java
)

Most of the work on the files seem to be done by Mark T. (awesome work, we
rely on this functionality heavily!) so I figured I would reach out and ask
about the doWrite() change to have a else block for blocking sockets. Is
this intended to fix the issue I am describing above?

I would check the history but I cannot seem to find the source for the
initial commit that introduces the else block for 8.5.x.

Thanks,
  -Rob

Re: Question on FORM POST processing via AJP1.3 in tomcat 1.0.69, changed from 1.014.

[Konstantin Kolinko]

2017-03-28 1:04 GMT+03:00 Olaf Kock :
>
>
> Am 27.03.2017 um 23:11 schrieb André Warnier (tomcat):
>> On 27.03.2017 23:03, Scott, Derric T wrote:
>>> I ran into a snag and finally identified the culprit.  The tomcat on
>>> the backend went from 1.0.14 to 1.0.69.
>> As far as I know, there exists no such Tomcat version. Where did you
>> get this from ?
>> (The current version is 8.5.(something)), major versions before that
>> were 8.0.x, 7.0.x, 6.0.x,..)
>
> Indeed, 3.2 was the first version of tomcat, as it continued the version
> numbers from whatever name it had before it was handed over to the
> apache foundation. It must have been the late 1990s when this happened.
> My memory blurs, but it might have started as the reference
> implementation of the servlet spec within Sun Microsystems.
>
> Funny enough, the 3.2 versions are not even available in the archives -
> they start at 3.3
>
> Oh, those memories...

You can find those versions here:
http://archive.apache.org/dist/tomcat/tomcat-3/archive/

Documentation isn't online though. The oldest being 3.2.x,
http://tomcat.apache.org/tomcat-3.2-doc/

Best regards,
Konstantin Kolinko

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

Re: Question on FORM POST processing via AJP1.3 in tomcat 1.0.69, changed from 1.014.

[Olaf Kock]

Am 27.03.2017 um 23:11 schrieb André Warnier (tomcat):
> On 27.03.2017 23:03, Scott, Derric T wrote:
>> I ran into a snag and finally identified the culprit.  The tomcat on
>> the backend went from 1.0.14 to 1.0.69.
> As far as I know, there exists no such Tomcat version. Where did you
> get this from ?
> (The current version is 8.5.(something)), major versions before that
> were 8.0.x, 7.0.x, 6.0.x,..)

Indeed, 3.2 was the first version of tomcat, as it continued the version
numbers from whatever name it had before it was handed over to the
apache foundation. It must have been the late 1990s when this happened.
My memory blurs, but it might have started as the reference
implementation of the servlet spec within Sun Microsystems.

Funny enough, the 3.2 versions are not even available in the archives -
they start at 3.3

Oh, those memories...

Olaf

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

Re: Question on FORM POST processing via AJP1.3 in tomcat 1.0.69, changed from 1.014.

[Konstantin Kolinko]

2017-03-28 0:03 GMT+03:00 Scott, Derric T :
> Hello:
>
> A question, perhaps a bug...
>
> I inherited a large application that has Apache in front, tomcat in back via 
> AJP1.3.  I am moving everything to
> "new" verisons.   A new RedHat OS, newest tomcat RPM (7.0.69), etc.
>
> I ran into a snag and finally identified the culprit.  The tomcat on the 
> backend went from 1.0.14 to 1.0.69.
> As I understand HTTP/HTML, a FORM is POSTed with two packets, the second one 
> is "DATA" - at least that
> is what I see from tcpdump, etc.  Note - this is only via the AJP1.3 port 
> 8009.  Access via port 8080 works fine.

The current version of Tomcat 7 is 7.0.76.

As you have a working test case, you can download versions from
Archive site [1] and pinpoint the pair that changed the behaviour.
With dichotomy that can be found in several steps. It is worth to test
with the current 7.0.76 as well.

[1] http://archive.apache.org/dist/tomcat/tomcat-7/

Best regards,
Konstantin Kolinko

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

Re: Question on FORM POST processing via AJP1.3 in tomcat 1.0.69, changed from 1.014.

[tomcat]

On 27.03.2017 23:03, Scott, Derric T wrote:

Hello:

A question, perhaps a bug...

I inherited a large application that has Apache in front, tomcat in back via 
AJP1.3.  I am moving everything to
"new" verisons.   A new RedHat OS, newest tomcat RPM (7.0.69), etc.

I ran into a snag and finally identified the culprit.  The tomcat on the 
backend went from 1.0.14 to 1.0.69.


As far as I know, there exists no such Tomcat version. Where did you get this 
from ?
(The current version is 8.5.(something)), major versions before that were 8.0.x, 7.0.x, 
6.0.x,..)



As I understand HTTP/HTML, a FORM is POSTed with two packets, the second one is 
"DATA" - at least that
is what I see from tcpdump, etc.  Note - this is only via the AJP1.3 port 8009. 
 Access via port 8080 works fine.

The bottom line is that a FORM, submitted using POST via AJP, with NO "DATA" 
packet, does NOT process as a form
submission, but instead returns a 400 HTTP error.  This is the code that is 
working now on 1.0.14, but will not
work on 1.0.69.

After a lot of experimentation, I determined that if I added ANYTHING that produced a 
"DATA" packet, then
it would work correctly.  First example:



This fails with 400 error.

Simply "naming" the submit button causes a "data" packet to be sent:

Causes success - and it makes a "DATA" packet to be sent with the value of the 
button variable:
submitbutton="Do the Java Thing"


First thing is : it is not really a "data packet". It is just a HTTP POST with/without 
body (content).




Second case is a completely blank form without even a submit button, called by 
a javascript routine.
Same results.  If I add any variable, say a hidden variable of "blah" with a 
value, it then works.

SO, question ...  between tomcat 1.0.14 and 1.0.69, what changed such that the behavior 
of the "POST"
data processing changed?   Is the current behavior correct and the old was 
wrong, or vice versa?
Short of touching some untold number of forms in this large application, is 
there any way to force
correct behavior, preferably via tomcat configs or something?



The first thing we would need to ascertain, is that you are really talking about tomcat. 
The versions above introduce a doubt..




Thanks!

Derric


The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.




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

Question on FORM POST processing via AJP1.3 in tomcat 1.0.69, changed from 1.014.

[Scott, Derric T]

Hello:

A question, perhaps a bug...

I inherited a large application that has Apache in front, tomcat in back via 
AJP1.3.  I am moving everything to
"new" verisons.   A new RedHat OS, newest tomcat RPM (7.0.69), etc.

I ran into a snag and finally identified the culprit.  The tomcat on the 
backend went from 1.0.14 to 1.0.69.
As I understand HTTP/HTML, a FORM is POSTed with two packets, the second one is 
"DATA" - at least that
is what I see from tcpdump, etc.  Note - this is only via the AJP1.3 port 8009. 
 Access via port 8080 works fine.

The bottom line is that a FORM, submitted using POST via AJP, with NO "DATA" 
packet, does NOT process as a form
submission, but instead returns a 400 HTTP error.  This is the code that is 
working now on 1.0.14, but will not
work on 1.0.69.

After a lot of experimentation, I determined that if I added ANYTHING that 
produced a "DATA" packet, then
it would work correctly.  First example:

   

This fails with 400 error.

Simply "naming" the submit button causes a "data" packet to be sent:
   
Causes success - and it makes a "DATA" packet to be sent with the value of the 
button variable:
   submitbutton="Do the Java Thing"

Second case is a completely blank form without even a submit button, called by 
a javascript routine.
Same results.  If I add any variable, say a hidden variable of "blah" with a 
value, it then works.

SO, question ...  between tomcat 1.0.14 and 1.0.69, what changed such that the 
behavior of the "POST"
data processing changed?   Is the current behavior correct and the old was 
wrong, or vice versa?
Short of touching some untold number of forms in this large application, is 
there any way to force
correct behavior, preferably via tomcat configs or something?

Thanks!

Derric


The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.

Re: Hot pre-compiled JSP reloading

[Joan Tomàs i Buliart]

On 27/03/17 11:39, André Warnier (tomcat) wrote:

On 27.03.2017 10:56, Mark Thomas wrote:

On 27/03/17 09:26, Olaf Kock wrote:




Other options that I can envision is to change Jasper's implementation
to keep serving a compiled JSP until the replacement has been properly
compiled and loaded in the background (e.g. not having compilation 
block

further requests to the same page). I haven't looked at the
implementation though and don't know a) if it's feasible and b) if you
like to dive that deep into the code to change tomcat's implementation.


a) is a solution I have just been thinking about. My initial impression
is that while the simple case is probably do-able, once you start
thinking about dependencies it could get very tricky, very fast.


Probably a practical case of :
https://en.wikipedia.org/wiki/No_free_lunch_theorem



I'd suggest looking at deploying as a single WAR and using parallel
deployment.

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

The main problem with the rolling deployment is that the JSP folder is a 
NFS shared along all the servers on the cluster, but we can manage some how.


In the case that we decide to try to extend Jasper to do this, any clue 
on which is the appropriate hook to use? That is, which class modify?


Many thanks in advance,

Joan

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

Re: Tomcat base directory layout

[Mark H. Wood]

On Sat, Mar 25, 2017 at 12:31:51PM +0100, Thomas Meyer wrote:
> Does there exists a small helper tool that can create the minimum necessary 
> directories and files in a new CATALINA-BASE directory ? Or a template zip 
> file or something like this?
> 
> Such a tool would be helpful, because I always struggle what directories are 
> minimum necessary to  start a new instance.

Not in the standard Tomcat kit, I think.  Gentoo Linux has its own
tomcat-instance-manager.bash script which does this.  You might be
able to adapt it.

https://wiki.gentoo.org/wiki/Apache_Tomcat

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu


signature.asc
Description: PGP signature

Re: LDAP authentication for Tomcat's webapp 'Opengrok'

[tomcat]

On 27.03.2017 13:07, Alfie Patolilic wrote:

-Original Message-
From: André Warnier (tomcat) [mailto:a...@ice-sa.com]
Sent: 27 March 2017 11:12
To: users@tomcat.apache.org
Subject: Re: LDAP authentication for Tomcat's webapp 'Opengrok'

On 27.03.2017 11:01, Alfie Patolilic wrote:

Tomcat Version : 6.0.36
OS : Red Hat Enterprise Linux 7.3

Hello,

I have a question on how I am able to set the following, regarding the web 
application that runs under Apache Tomcat, 'Opengrok'. The idea is to set a 
hostname for 'localhost:8080/grok', so when users try and access the page via 
the hostname, they are prompted for authentication of their username and 
password.
I have currently configured the server.xml to connect to LDAP. I have added 
below the configuration on my server.xml. I am unsure as to where to go from 
here, how I will be able to link the hostname. I have changed some values in 
the information given for security purposes.



  
  


I have checked the web for blogs and asked other tomcat groups but was not able 
to get any answers.

I am aware that the version of Apache Tomcat I am using is outdated and has 
reached its end of life. Though necessary, I cannot update to a newer version 
of the application due to some issues.

Hi.

I believe that you are confused about 2 separate topics : "hostnames" and "web 
application
security".
It is the web application which is "protected" by a userid/password login 
requirement, not
the hostname.
This page of the on-line tomcat 6 documentation provides some hints :
http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html
In the "Quick Start" section, you will see that in order to "force" someone to
authenticate in order to use the application, you need to specify some things 
in the
web.xml of the application.
And in the "Example Application" section, it points to an example application 
that has
these things.
Maybe you can start from there ?

And for the "host name" part, see this section :
http://tomcat.apache.org/tomcat-6.0-doc/virtual-hosting-howto.html
But that is a different issue.




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


Hi André,

Thank you for the reply, I apologize for the unclear question, It is just one 
host instance.
I meant that currently, I can access opengrok via localhost:8080/grok . I am 
planning on configuring a hostname called 'grok.company.com' which redirects to 
localhost:8080/grok.
When they access grok using grok.company.com, they will be prompted with a 
userid and password using LDAP. I have configured the Realm element as stated 
on the previous message.



That is what I meant : you /are/ confused.
It is not when "they" will access "http://grok.company.com; that they will be prompted for 
a user-id and password. It is when they will access /an application/ running under that 
host that they will be prompted, /if/ this application is configured to require a 
user-id/password.
And, the realm that you configured, will help, in the sense that /in the application 
configuration/, you will tell tomcat to use this realm, as a "how" to do the 
authentication precisely.


A separate issue is of you want to make your "grok" application be the tomcat default 
application (normally, the default application is called "ROOT").

And for that, look at this article :
https://wiki.apache.org/tomcat/HowTo#How_do_I_make_my_web_application_be_the_Tomcat_default_application.3F




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

RE: LDAP authentication for Tomcat's webapp 'Opengrok'

[Alfie Patolilic]

-Original Message-
From: André Warnier (tomcat) [mailto:a...@ice-sa.com] 
Sent: 27 March 2017 11:12
To: users@tomcat.apache.org
Subject: Re: LDAP authentication for Tomcat's webapp 'Opengrok'

On 27.03.2017 11:01, Alfie Patolilic wrote:
> Tomcat Version : 6.0.36
> OS : Red Hat Enterprise Linux 7.3
>
> Hello,
>
> I have a question on how I am able to set the following, regarding the web 
> application that runs under Apache Tomcat, 'Opengrok'. The idea is to set a 
> hostname for 'localhost:8080/grok', so when users try and access the page via 
> the hostname, they are prompted for authentication of their username and 
> password.
> I have currently configured the server.xml to connect to LDAP. I have added 
> below the configuration on my server.xml. I am unsure as to where to go from 
> here, how I will be able to link the hostname. I have changed some values in 
> the information given for security purposes.
>
> 
>
>   resourceName="UserDatabase"/>
>   connectionURL="ldap:// "
> connectionName="ldap@company "
> connectionPassword="password"
> referrals="follow"
> userBase="DC="
> userSearch="(sAMAccountName={0})"
> userSubtree="true"
> roleBase="DC="
> roleName="cn"
> roleSubtree="true"
> roleSearch="(member={0})"
> allRolesMode="strictAuthOnly"
> />
>
>
> I have checked the web for blogs and asked other tomcat groups but was not 
> able to get any answers.
>
> I am aware that the version of Apache Tomcat I am using is outdated and has 
> reached its end of life. Though necessary, I cannot update to a newer version 
> of the application due to some issues.
>
> Hi.
>
> I believe that you are confused about 2 separate topics : "hostnames" and 
> "web application 
> security".
> It is the web application which is "protected" by a userid/password login 
> requirement, not 
> the hostname.
> This page of the on-line tomcat 6 documentation provides some hints :
> http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html
> In the "Quick Start" section, you will see that in order to "force" someone 
> to 
> authenticate in order to use the application, you need to specify some things 
> in the 
> web.xml of the application.
> And in the "Example Application" section, it points to an example application 
> that has 
> these things.
> Maybe you can start from there ?
>
> And for the "host name" part, see this section :
> http://tomcat.apache.org/tomcat-6.0-doc/virtual-hosting-howto.html
> But that is a different issue.


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

Hi André,

Thank you for the reply, I apologize for the unclear question, It is just one 
host instance.
I meant that currently, I can access opengrok via localhost:8080/grok . I am 
planning on configuring a hostname called 'grok.company.com' which redirects to 
localhost:8080/grok.
When they access grok using grok.company.com, they will be prompted with a 
userid and password using LDAP. I have configured the Realm element as stated 
on the previous message.

Thank you,
Alfie

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

Re: LDAP authentication for Tomcat's webapp 'Opengrok'

[tomcat]

On 27.03.2017 11:01, Alfie Patolilic wrote:

Tomcat Version : 6.0.36
OS : Red Hat Enterprise Linux 7.3

Hello,

I have a question on how I am able to set the following, regarding the web 
application that runs under Apache Tomcat, 'Opengrok'. The idea is to set a 
hostname for 'localhost:8080/grok', so when users try and access the page via 
the hostname, they are prompted for authentication of their username and 
password.
I have currently configured the server.xml to connect to LDAP. I have added 
below the configuration on my server.xml. I am unsure as to where to go from 
here, how I will be able to link the hostname. I have changed some values in 
the information given for security purposes.


   
 
 
   

I have checked the web for blogs and asked other tomcat groups but was not able 
to get any answers.

I am aware that the version of Apache Tomcat I am using is outdated and has 
reached its end of life. Though necessary, I cannot update to a newer version 
of the application due to some issues.


Hi.

I believe that you are confused about 2 separate topics : "hostnames" and "web application 
security".
It is the web application which is "protected" by a userid/password login requirement, not 
the hostname.

This page of the on-line tomcat 6 documentation provides some hints :
http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html
In the "Quick Start" section, you will see that in order to "force" someone to 
authenticate in order to use the application, you need to specify some things in the 
web.xml of the application.
And in the "Example Application" section, it points to an example application that has 
these things.

Maybe you can start from there ?

And for the "host name" part, see this section :
http://tomcat.apache.org/tomcat-6.0-doc/virtual-hosting-howto.html
But that is a different issue.



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

Re: Hot pre-compiled JSP reloading

[tomcat]

On 27.03.2017 10:56, Mark Thomas wrote:

On 27/03/17 09:26, Olaf Kock wrote:




Other options that I can envision is to change Jasper's implementation
to keep serving a compiled JSP until the replacement has been properly
compiled and loaded in the background (e.g. not having compilation block
further requests to the same page). I haven't looked at the
implementation though and don't know a) if it's feasible and b) if you
like to dive that deep into the code to change tomcat's implementation.


a) is a solution I have just been thinking about. My initial impression
is that while the simple case is probably do-able, once you start
thinking about dependencies it could get very tricky, very fast.


Probably a practical case of :
https://en.wikipedia.org/wiki/No_free_lunch_theorem



I'd suggest looking at deploying as a single WAR and using parallel
deployment.

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

LDAP authentication for Tomcat's webapp 'Opengrok'

[Alfie Patolilic]

Tomcat Version : 6.0.36
OS : Red Hat Enterprise Linux 7.3

Hello,

I have a question on how I am able to set the following, regarding the web 
application that runs under Apache Tomcat, 'Opengrok'. The idea is to set a 
hostname for 'localhost:8080/grok', so when users try and access the page via 
the hostname, they are prompted for authentication of their username and 
password.
I have currently configured the server.xml to connect to LDAP. I have added 
below the configuration on my server.xml. I am unsure as to where to go from 
here, how I will be able to link the hostname.


  

ldap://dubitdcvm01.openet-dublin:389;
   connectionName="jiraldap@openet-dublin"
   connectionPassword="jiraldap"
   referrals="follow"
   userBase="DC=openet-dublin"
   userSearch="(sAMAccountName={0})"
   userSubtree="true"
   roleBase="DC=openet-dublin"
   roleName="cn"
   roleSubtree="true"
   roleSearch="(member={0})"
   allRolesMode="strictAuthOnly"
   />
  

I have checked the web for blogs and asked other tomcat groups but was not able 
to get any answers.

I am aware that the version of Apache Tomcat I am using is outdated and has 
reached its end of life. Though necessary, I cannot update to a newer version 
of the application due to some issues.

Kind Regards,
Alfie

LDAP authentication for Tomcat's webapp 'Opengrok'

[Alfie Patolilic]

Tomcat Version : 6.0.36
OS : Red Hat Enterprise Linux 7.3

Hello,

I have a question on how I am able to set the following, regarding the web 
application that runs under Apache Tomcat, 'Opengrok'. The idea is to set a 
hostname for 'localhost:8080/grok', so when users try and access the page via 
the hostname, they are prompted for authentication of their username and 
password.
I have currently configured the server.xml to connect to LDAP. I have added 
below the configuration on my server.xml. I am unsure as to where to go from 
here, how I will be able to link the hostname. I have changed some values in 
the information given for security purposes.


  


  

I have checked the web for blogs and asked other tomcat groups but was not able 
to get any answers.

I am aware that the version of Apache Tomcat I am using is outdated and has 
reached its end of life. Though necessary, I cannot update to a newer version 
of the application due to some issues.

Kind Regards,
Alfie

Recall: LDAP authentication for Tomcat's webapp 'Opengrok'

[Alfie Patolilic]

Alfie Patolilic would like to recall the message, "LDAP authentication for 
Tomcat's webapp 'Opengrok'".
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Hot pre-compiled JSP reloading

[Mark Thomas]

On 27/03/17 09:26, Olaf Kock wrote:



> Other options that I can envision is to change Jasper's implementation
> to keep serving a compiled JSP until the replacement has been properly
> compiled and loaded in the background (e.g. not having compilation block
> further requests to the same page). I haven't looked at the
> implementation though and don't know a) if it's feasible and b) if you
> like to dive that deep into the code to change tomcat's implementation.

a) is a solution I have just been thinking about. My initial impression
is that while the simple case is probably do-able, once you start
thinking about dependencies it could get very tricky, very fast.

I'd suggest looking at deploying as a single WAR and using parallel
deployment.

Mark


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

Recall: LDAP authentication for Tomcat's webapp 'Opengrok'

[Alfie Patolilic]

Alfie Patolilic would like to recall the message, "LDAP authentication for 
Tomcat's webapp 'Opengrok'".
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Hot pre-compiled JSP reloading

[Olaf Kock]

Am 27.03.2017 um 09:30 schrieb Joan Tomàs i Buliart:
> Hello,
>
> We currently deploy our JSPs outside of the WAR. This allows us to
> deploy the main application container and the JSP views at different
> pace (one team moves much faster than the other).  In order to support
> this, we have JSPs out of the war. When the webapp is deployed some
> soft-links are created to the folders the JSPs are. Finally, when we
> deploy new/updated JSPs, the JspServlet detects it, recompiles the
> new/updated JSPs and replaces the classes.
>
> This workflow works fine when the changes are little and the servers
> load average is low. The problem comes when a developer modifies one
> of the main JSPs or the load of the servers is high. In this
> situation, all the servers starts to compile the updated JSP and, due
> to the amount of load, lots of request end up throwing 504 errors.
>
> We are considering to pre-compile the JSPs before deploying them to
> the server. The problem is that we are not able to find any option to
> force Tomcat to hot reload ONLY the updated classes. All the different
> reload options that we have tested end up reloading all the webapp
> (which means 80s of downtime for us).
>
> Is there any recommended option to manage this? Does somebody have a
> similar scenario or a suitable solution?
>
Joan Tomàs,

You're asking for a workaround to a workaround that you've configured -
i.e. your deployment strategy is quite unusual, and you're finding the
setbacks. For tomcat, a web application is the unit of deployment, and
the basic behaviour is to not expect sudden changes. In fact, to most
people I do recommend to keep proper procedures, e.g. for disaster
recovery, to fully automatically deploy everything, all the time.

The production settings at
https://tomcat.apache.org/tomcat-8.5-doc/jasper-howto.html say
> "The main JSP optimization which can be done is precompilation of
JSPs. However, this might not be possible (for example, when using the
jsp-property-group feature) or practical, in which case the
configuration of the Jasper servlet becomes critical."

That being said, you have 80s downtime when redeploying the web
application, which makes it impractical to do precompilation of JSPs
(the way that Jasper was designed).

To me, not accepting 80s downtime implies that you are already running a
cluster, and you might be happy with rolling updates - e.g. take one
machine out of your loadbalancer's rotation, update it, (optionally warm
up caches) and introduce it again. If you have sticky sessions, it might
take an hour or three until most sessions have timed out, but fully
automated, you can be sure that sooner or later your JSPs are updated -
not all at the same time though.

This strategy might even allow you to keep your current workaround up,
as it only implies the update to be done while the server doesn't get
any request to serve. It does not imply a full redeploy of the
application (though that would be my default)

Other options that I can envision is to change Jasper's implementation
to keep serving a compiled JSP until the replacement has been properly
compiled and loaded in the background (e.g. not having compilation block
further requests to the same page). I haven't looked at the
implementation though and don't know a) if it's feasible and b) if you
like to dive that deep into the code to change tomcat's implementation.

Olaf




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

Re: Hot pre-compiled JSP reloading

[Joan Tomàs i Buliart]

Hello,


We currently deploy our JSPs outside of the WAR. This allows us to 
deploy the main
application container and the JSP views at different pace (one team 
moves much faster than
the other).  In order to support this, we have JSPs out of the war. 
When the webapp is
deployed some soft-links are created to the folders the JSPs are. 
Finally, when we deploy
new/updated JSPs, the JspServlet detects it, recompiles the 
new/updated JSPs and replaces

the classes.

This workflow works fine when the changes are little and the servers 
load average is low.
The problem comes when a developer modifies one of the main JSPs or 
the load of the
servers is high. In this situation, all the servers starts to compile 
the updated JSP and,

due to the amount of load, lots of request end up throwing 504 errors.

We are considering to pre-compile the JSPs before deploying them to 
the server. The
problem is that we are not able to find any option to force Tomcat to 
hot reload ONLY the
updated classes. All the different reload options that we have tested 
end up reloading all

the webapp (which means 80s of downtime for us).

Is there any recommended option to manage this? Does somebody have a 
similar scenario or a

suitable solution?


Hi.
I cannot help you personally, and this will have to wait for a real 
expert.
But thanks in any case for the clear and succint description of the 
issue, I am sure that will help you get some answers quickly.


Maybe one additional information might help someone to help you : the 
precise version of Tomcat which this is related to (options may differ 
depending on the version).

And while you're at it, throw in the platform and JVM too.



Hi André,

we are using Tomcat 8.0.12 with jvm 1.8.0_92 on Linux (aws and ubuntu).
We are starting the migration to 8.5.12.

Many thanks in advance,

Tomàs



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

Re: Hot pre-compiled JSP reloading

[tomcat]

On 27.03.2017 09:30, Joan Tomàs i Buliart wrote:

Hello,

We currently deploy our JSPs outside of the WAR. This allows us to deploy the 
main
application container and the JSP views at different pace (one team moves much 
faster than
the other).  In order to support this, we have JSPs out of the war. When the 
webapp is
deployed some soft-links are created to the folders the JSPs are. Finally, when 
we deploy
new/updated JSPs, the JspServlet detects it, recompiles the new/updated JSPs 
and replaces
the classes.

This workflow works fine when the changes are little and the servers load 
average is low.
The problem comes when a developer modifies one of the main JSPs or the load of 
the
servers is high. In this situation, all the servers starts to compile the 
updated JSP and,
due to the amount of load, lots of request end up throwing 504 errors.

We are considering to pre-compile the JSPs before deploying them to the server. 
The
problem is that we are not able to find any option to force Tomcat to hot 
reload ONLY the
updated classes. All the different reload options that we have tested end up 
reloading all
the webapp (which means 80s of downtime for us).

Is there any recommended option to manage this? Does somebody have a similar 
scenario or a
suitable solution?


Hi.
I cannot help you personally, and this will have to wait for a real expert.
But thanks in any case for the clear and succint description of the issue, I am sure that 
will help you get some answers quickly.


Maybe one additional information might help someone to help you : the precise version of 
Tomcat which this is related to (options may differ depending on the version).

And while you're at it, throw in the platform and JVM too.




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

Hot pre-compiled JSP reloading

[Joan Tomàs i Buliart]

Hello,

We currently deploy our JSPs outside of the WAR. This allows us to 
deploy the main application container and the JSP views at different 
pace (one team moves much faster than the other).  In order to support 
this, we have JSPs out of the war. When the webapp is deployed some 
soft-links are created to the folders the JSPs are. Finally, when we 
deploy new/updated JSPs, the JspServlet detects it, recompiles the 
new/updated JSPs and replaces the classes.


This workflow works fine when the changes are little and the servers 
load average is low. The problem comes when a developer modifies one of 
the main JSPs or the load of the servers is high. In this situation, all 
the servers starts to compile the updated JSP and, due to the amount of 
load, lots of request end up throwing 504 errors.


We are considering to pre-compile the JSPs before deploying them to the 
server. The problem is that we are not able to find any option to force 
Tomcat to hot reload ONLY the updated classes. All the different reload 
options that we have tested end up reloading all the webapp (which means 
80s of downtime for us).


Is there any recommended option to manage this? Does somebody have a 
similar scenario or a suitable solution?


Many thanks in advance,


Joan

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