Re: web-fragment.xml in embedded containers

[Violeta Georgieva]

Hi,

2017-01-24 5:20 GMT+02:00 John D. Ament :
>
> Hi,
>
> I was wondering if there was some configuration option that I could enable
> in an embedded Tomcat container to have it process web-fragment.xml files?

What is the case where an embedded Tomcat does not process web-fragment.xml
files?

Regards,
Violeta

> John

web-fragment.xml in embedded containers

[John D. Ament]

Hi,

I was wondering if there was some configuration option that I could enable
in an embedded Tomcat container to have it process web-fragment.xml files?

John

RE: After upgrade to Tomcat 7.0.72+, JSF Error: FacesContext already released in JSF tools with

[Hadas Toronchik]

I there any expectation as to when 7.0.74 is going to be released?


Much Thanks,
Hadas
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Tuesday, January 17, 2017 9:58 PM
To: Tomcat Users List 
Subject: Re: After upgrade to Tomcat 7.0.72+, JSF Error: FacesContext already 
released in JSF tools with

On 15/01/2017 19:52, Hadas Toronchik wrote:
> We have a JSF based application, and we upgraded tomcat to 7.0.72 
> Since then , several hours after the tomcat starts we receive JSF 
> Exceptions when just trying to open JSF based pages that worked fine before 
> If we clean all Generated Servlet pages it goes away again for a couple of 
> hours.

Possibly related to the tag reuse changes. 7.0.74 should be available in a few 
days that contains the necessary fixes.

Mark


> Another company reported a similar issue: 
> https://jira.sakaiproject.org/browse/SAK-31912 - they say that after 
> downgrading to 7.0.70 the problem disappears...
> 
> Here is the Exception:
> 2017-01-10 13:49:37,490 ERROR [http-nio-0.0.0.0-8080-exec-24] [UID:, 
> MSG_ID:] 
> [org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/].[js
> p]] 
> java.lang.IllegalStateException: FacesContext already released
>at 
> org.apache.myfaces.context.servlet.ServletFacesContextImpl.getResponseWriter(ServletFacesContextImpl.java:241)
>  ~[myfaces-impl-1.1.5.jar:1.1.5]
>at 
> javax.faces.webapp.UIComponentTag.setupResponseWriter(UIComponentTag.java:933)
>  ~[myfaces-api-1.1.5.jar:1.1.5]
>at 
> javax.faces.webapp.UIComponentTag.doStartTag(UIComponentTag.java:313) 
> ~[myfaces-api-1.1.5.jar:1.1.5]
>at 
> org.apache.jsp.app.layout.include2.search_jsp._jspService(search_jsp.java:239)
>  ~[na:na]
>at 
> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) 
> [jasper.jar:7.0.73]
>at 
> javax.servlet.http.HttpServlet.service(HttpServlet.java:731) 
> [servlet-api.jar:na]
>at 
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:439)
>  [jasper.jar:7.0.73]
>at 
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:395) 
> [jasper.jar:7.0.73]
>at 
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:339) 
> [jasper.jar:7.0.73]
>at 
> javax.servlet.http.HttpServlet.service(HttpServlet.java:731) 
> [servlet-api.jar:na]
>at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
>  [catalina.jar:7.0.73]
>at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>  [catalina.jar:7.0.73]
>at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:747)
>  [catalina.jar:7.0.73]
>at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:603)
>  [catalina.jar:7.0.73]
>at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:542)
>  [catalina.jar:7.0.73]
>at 
> org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:897)
>  [jasper.jar:7.0.73]
>at 
> org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:656) 
> [jasper.jar:7.0.73]
>at 
> org.apache.struts.tiles.TilesUtilImpl.doInclude(TilesUtilImpl.java:137) 
> [panaya-struts-1.1.jar:1.1]
>at 
> org.apache.struts.tiles.TilesUtil.doInclude(TilesUtil.java:177) 
> [panaya-struts-1.1.jar:1.1]
>at 
> org.apache.struts.taglib.tiles.InsertTag.doInclude(InsertTag.java:756) 
> [panaya-struts-1.1.jar:1.1]
>at 
> org.apache.struts.taglib.tiles.InsertTag$InsertHandler.doEndTag(InsertTag.java:881)
>  [panaya-struts-1.1.jar:1.1]
>at 
> org.apache.struts.taglib.tiles.InsertTag.doEndTag(InsertTag.java:473) 
> [panaya-struts-1.1.jar:1.1]
>at 
> org.apache.jsp.app.layout.mainLayout2_jsp._jspx_meth_t_005finsert_005f2(mainLayout2_jsp.java:2062)
>  [_/:na]
>at 
> org.apache.jsp.app.layout.mainLayout2_jsp._jspx_meth_f_005fview_005f0(mainLayout2_jsp.java:408)
>  [_/:na]
>at 
> org.apache.jsp.app.layout.mainLayout2_jsp._jspService(mainLayout2_jsp.java:310)
>  [_/:na]
>at 
> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) 
> [jasper.jar:7.0.73]
>at 
> javax.servlet.http.HttpServlet.service(HttpServlet.java:731) 
> [servlet-api.jar:na]
>at 
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:439)
>  [jasper.jar:7.0.73]
>at 
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:395) 
> [jasper.jar:7.0.73]
>at 
> 

Re: Separate and Redirect Tomcat Embedded 8.5.6 Log

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Costin,

On 1/20/17 5:39 AM, Costin Giorgian Papuc wrote:
> I have an app that can take a war file and deploy it with embedded 
> tomcat .5.6. So, for each uploaded war file I do the following
> 
> Tomcat tomcat = new Tomcat(); tomcat.setPort(port); File
> catalinaHome = new File(TOMCAT_DIR + port); catalinaHome.mkdirs(); 
> File webapp = new File(TOMCAT_DIR + port +
> "\\webapps"); webapp.mkdir(); 
> tomcat.setBaseDir(catalinaHome.getAbsolutePath());
> 
> try { File war = new File("myapp.war"); //the given war file 
> StandardContext context = (StandardContext)
> tomcat.addWebapp("/myapp", war.getAbsolutePath()); 
> context.setAntiResourceLocking(true); tomcat.start(); } catch
> (Exception e) { e.printStackTrace(); }
> 
> I don't have any idea how can I redirect the output. I read that
> tomcat embedded log to System.out, and I was able to redirect to
> file with: PrintStream out = new PrintStream(new
> FileOutputStream("output.txt")); System.setOut(out); but redirect
> all output, and I want something that log to a different file for
> each tomcat instance that I run. Any solution that I found so far
> don't resolve my problem. So, how can I separate output for each
> tomcat instance?

Try setting swallowOutput="true" [1] for each of the contexts you deploy
.

- -chris

[1] https://tomcat.apache.org/tomcat-8.0-doc/config/context.html
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYhoQAAAoJEBzwKT+lPKRYp+QP/2CxRxua+yW1riHubZilKoy/
R3cDpMQuN7UIOIsgr5ImO8ST7/vAdAkvXMB1bastJ5Btbtc6+K5hdv6HGQb86fT7
aKsut81O3VzBuwBiLIkhyjEDxAT3WU3WVS7BY/hnoDvVeRRS98Kat0tuzJZEPT/e
K8NFnwU7x7jCgI+ruf888O0ukhib1t/9DXjuY/fW9h0moJJDttbo8D6//Dh9H2zd
YvO6n7yIIIAs5FHmJIH4RwP7xOqaMDStGZBxi1cqkaZOcp4ZeCdEi0kekQwhCSK+
bPZ1zNp6fdOYfVIWhAqic44CUSDZmdWMNp3KZ5Ei2/VFllpE+lDYaTvS9TfyEP+n
XxkW03zEFm9QHVIo/35Jbp3mj7YnuJpjvnLOCWrWEvxas+omwJZGbTKlQRNHVTi/
Ez2uKUcJoTfvf9UXqdFDDSncnL7J9YcN7mp1M5tqCxiVkokAZWQs272WDpghNMdl
4Y22rjJJqnRnlr1UpXz/+RHzInl2Jt8yEzC4Ta8zBv1urSSucYQwbTHkNhLerZqT
0Kq4O+OaZEU0sbrG+iHPKCccoIr3i/vpN306F9yCSdSA1aLlWeJqwwL0184JzEXm
pgS1FMDLCLHeRLl6eVhMWegAful13ABQ3DCVayLmR2/a3S5kq484V2OhLsgeAKxH
8iim5GKxss+o/JHB6W89
=qtf5
-END PGP SIGNATURE-

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

Re: Tomcat 8.0.41 release date and CVE-2016-8735

[Mark Thomas]

On 23/01/2017 20:18, Nikola Vouk wrote:
>I've been reviewing the release logs on the security fixes going into 
> tomcat 
> (https://tomcat.apache.org/security-8.html#Fixed_in_Apache_Tomcat_8.0.40) , 
> and I would like to ask if you could clarify a couple of things for me please:
> 
> 
> 1)  8.0.41 release date:
> 8.0.40 seems to have been indefinitely shelved but it contains the fix for 
> CVE-2016-8745. 
> The change log says 'release in progress', but what is the time expected for 
> the release to be completed --- days or weeks?

The release vote takes place on the dev list. You can following along
there. The release looks to be imminent (assuming no regression is found).

> 2)  
> CVE-2016-8735 
> bug fix id:
> The change log for 8.0.39 says that 
> CVE-2016-8735 
> was fixed in  1767656 but 
> that points directly to the code change. I couldn't find any bugfix 
> specifically for that issue so I'm guessing it was code only change?

Not every change has an associated Bugzilla entry.

> 3)  Reserved CVEs updated in NVD
> A number of the more recent CVEs are still in the reserved state in NVD. Are 
> there plans to update NVD with the details? When NVD gets updated, all the 
> world's scanners start processing it and flagging the software for the fixes.

That is fairly typical for Mitre. There is a new(ish) web form that can
be used to provide updates if Mitre miss them.

Mark


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

Tomcat 8.0.41 release date and CVE-2016-8735

[Nikola Vouk]

   I've been reviewing the release logs on the security fixes going into tomcat 
(https://tomcat.apache.org/security-8.html#Fixed_in_Apache_Tomcat_8.0.40) , and 
I would like to ask if you could clarify a couple of things for me please:


1)  8.0.41 release date:
8.0.40 seems to have been indefinitely shelved but it contains the fix for 
CVE-2016-8745. The 
change log says 'release in progress', but what is the time expected for the 
release to be completed --- days or weeks?

2)  
CVE-2016-8735 bug 
fix id:
The change log for 8.0.39 says that 
CVE-2016-8735 was 
fixed in  1767656 but that 
points directly to the code change. I couldn't find any bugfix specifically for 
that issue so I'm guessing it was code only change?

3)  Reserved CVEs updated in NVD
A number of the more recent CVEs are still in the reserved state in NVD. Are 
there plans to update NVD with the details? When NVD gets updated, all the 
world's scanners start processing it and flagging the software for the fixes.

Thank you,
Nikola

RE: https redirect failed for POST request when behind a load balancer

[Bin Chen]

Peter:
To answer your questions
1. The response header when using 8080 to post, I got:

Status Code: 405 Method Not Allowed
Allow: POST
Cache-Control: private
Content-Language: en
Content-Length: 1045
Content-Type: text/html;charset=utf-8
Date: Mon, 23 Jan 2017 18:48:07 GMT
Expires: Wed, 31 Dec 1969 16:00:00 PST
Server: Apache-Coyote/1.1

This agrees to the access log record

When using 8443 for the same POST operation, I got:

Status Code: 201 Created
Content-Length: 277
Content-Type: application/xml
Date: Mon, 23 Jan 2017 18:51:25 GMT
Server: Apache-Coyote/1.1

Which also agrees to the access log record.

For your second question:
I understand the risk and consequence of using redirect for POST, this is just 
an alternative for us for a short period of time, we will force all our users 
to move the https before we can shut down the 8080 for POST. We are working on 
that in the meantime.

Thank you very much,

Bin 


-Original Message-



The redirect takes place in the client. What kind of client do you use? Could 
you send us the response headers from the two setups?



You did not answer on my recommendation to fix the app to be https from the 
start. In that case the redirect will be unnecessary...



Peter

Re: ExtendedAccessLogValve.class overloaded timezone and set it to GMT

[tomcat]

On 23.01.2017 16:38, Christopher Schultz wrote:

I'm curious... what's wrong with GMT?


I have been wondering about that too.  It seems a rather bad idea to me, as it brings 
potential problems of compatibility with log-exploiting programs, hosting servers 
somewhere else, comparing time between different computers and applications etc.
Not even mentioning issues of future tomcat updates, re-calculating the times when users 
send problem reports and so on.


Would it not be better if it was an external utility which reads the logs, that makes any 
adjustments required ?
I'd bet that some external perl script, 10 lines max, would filter these files in no time 
at all.



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

Re: FW: tomcat 8080 thread not reduced

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Smith,

On 1/22/17 1:37 AM, smith wrote:
> We don't just care about free, we care about active too. We know
> how many free also means how many are active

If you are using a dynamically-sized pool, then you don't really know
how many you have free if you sample active, or how many you have
active if you sample free ones. You have to collect both stats in
order to know whether or not there is a problem.

Of course, the size of the pool can chance between samples of
free/active so you are never getting a perfect picture.

> We are using HTTP

That wasn't clear from any of your previous posts. In that case
keepalive could be an issue. The solution is to use a NIO connector.

> Let's me take one example from manager status: (this is the
> manager output) Max threads: 200 Current thread count: 23 Current
> thread busy: 1 Keeped alive sockets count: 1
> 
> Current thread count: 23 I want to know if these 23 threads are
> free to use, or they are active, cannot accept new connection? Here
> are Keeped alive sockets count, it's only 1, is this 1 for the
> busy thread or a thread in 23?

The current thread count tells you how many java.lang.Thread objects
are being managed by the thread pool. It says nothing about their
state. The 200 is obviously the limit of threads that *would* be
managed by the pool.

I would have to read the code to find out if a keep-alive connection
counts as "busy" or not. But you don't want keepAlive connections to
hold-up a thread, so you should use an NIO connector.

Since you are using Tomcat 8 (albeit an old version) without
specifying a certain type of connector, you are already getting either
the NIO connector or the APR connector (if the native library is
available). Neither of those connectors will hold-up a thread for a
keepalive connection.

I suspect that "busy:1, keepalive:1" for you means that there is
currently 1 thread actually processing a request, and you have 22
threads idle. The keepalive:1 means that one socket connection is in
the keepalive state, but it's not consuming a thread.

- -chris

> -Original Message- From: Christopher Schultz 
> [mailto:ch...@christopherschultz.net] Sent: Friday, January 20,
> 2017 10:29 PM To: Tomcat Users List Subject: Re: FW: tomcat 8080
> thread not reduced
> 
> Smith,
> 
> On 1/19/17 9:59 PM, smith wrote:
>>> "busy" is the same as "active".
> 
>> When not use , our busy thread always keep under 10
>> while the currentThreadCount keeps high (these are get from
>> tomcat manager), So we really don't know how many threads are
>> truly free.
> 
> Why do you care how many are free? Isn't it more important to know 
> how many are active? For example, I run my app servers with 
> maxThreads="150" for the most part. Then, I have Nagios notify me
> if the "active count" goes above 135 (that's 90% of my
> maxThreads).
> 
> Nagios, like many monitoring systems, won't scream the first time
> it sees something. Instead, it will check again a few times before 
> complaining. That means that as long as I don't see any
> significant duration where the active thread count exceeds 135, I
> don't get any alarms going off.
> 
> And I don't care how many "free" threads I have. I've decided that
> I want "150 and NO MORE". Nothing else matters except the active 
> count. I don't happen to allow the thread pool to re-size downward 
> (fewer threads), but if I did, I wouldn't have to change my 
> monitoring at all. What? The active count is 10 and the total pool 
> size is 20? I don't care. Wake me up when the active thread count 
> stays high for a while, indicating to me that we are getting 
> hammered.
> 
>> How many are in keepAlivedStatus
> 
> Use NIO and forget about it.
> 
> Besides, you are using *AJP*. Every thread is *always* in a
> keepalive state. So keepalive == idle as far as Tomcat is
> concerned.
> 
> If you were using HTTP, then keepalive would be an issue (and NIO 
> would be the answer), but you aren't, so it's not.
> 
> -chris
> 
>> -Original Message- From: Christopher Schultz 
>> [mailto:ch...@christopherschultz.net] Sent: Thursday, January 19,
>>  2017 4:38 PM To: Tomcat Users List Subject: Re: FW: tomcat 8080 
>> thread not reduced
> 
>> Smith,
> 
>> On 1/18/17 8:25 PM, smith wrote:
>>> I don't care if the threads will be reduced, I just want to
>>> know why.
> 
>> Okay.
> 
>>> And we want to use the account to determine when the tomcat 
>>> capacity is not enough that we need to add max configuration
>>> or add new tomcat servers.
> 
>> Set your initial and max threads to the same value (pool size = 
>> constant) and then monitor the "active count" with a Nagios
>> warning at e.g. 80% usage.
> 
>>> Since not use the , the busy thread account also
>>> cannot tell us the correct active threads count.
> 
>> "busy" is the same as "active".
> 
>>> In another email thread, you said if use , it will
>>> tell us the right active thread count not just busy count,
>>> right?
> 
>> 

Re: ExtendedAccessLogValve.class overloaded timezone and set it to GMT

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Farhan,

On 1/21/17 2:20 AM, Farhan Tariq wrote:
> hi,
> 
> we have tomcat 7.0.68 deployed on linux.
> 
> To capture the log in local system timezone using
> ExtendedAccessLogValve class we change the following line 
> "currentTimestampFormat.setTimeZone(TimeZone.getTimeZone("GMT"))"
> 
> into "currentTimestampFormat.setTimeZone(TimeZone.getDefault())"
> 
> in ElementTimestampStruct class and then compile and replace the 
> catalina.jar in already deployed tomcat.
> 
> Now , The time is sync with the system set time which is GMT+5 but
> somehow date is still operating on GMT as date get changed at 05:00
> AM ( system time). please help me in this regard to understand why
> the above mentioned change have no impact of date field.

Are you saying that at 05:00, the timestamps in your log file look
like this:

2017-01-23 04:59:58 Something happened
2017-01-23 04:59:59 Something happened
2017-01-24 05:00:00 Something happened
2017-01-24 05:00:01 Something happened

?

What does TimeZone.getDefault() return in your environment?

The java.util.Date object in ExtendedAccessLog recons time using only
the epoch time (milliseconds since 1970 in GMT), and always deals with
it as a long integer value. Only the DateFormat should be making any
interpretation at all as to how to format the date.

However, the value of that date only changes once per INTERVAL
milliseconds, and it changes based upon the GMT date. So your
experience is expected given the code.

Your attempt to change the time zone to something non-GMT isn't
compatible with the performance optimizations that have been made to
that class. If you want to completely change the time zone from GMT to
e.g. GMT+5, then you'll need to adjust the epoch time stored in
currentTimestamp by setting it forward by 5 hours.

A single adjustment is not adequate, because the date value coming
from the request for logging will be off by 5 hours each time, and
that value is used to update the cached value.

I don't believe it is going to be easy for you to change the time zone
with such a simple change to your code. You will need to add the
timezone adjustment each time a calculation is performed. For example:

// ExtendedAccessLog.java:217 (tc9/trunk)
long millis = eds.currentTimestamp.getTime();
if (date.getTime() > (TZ_ADJ + millis + INTERVAL -1) ||
date.getTime() < (TZ_ADJ + millis)) {
eds.currentTimestamp.setTime(
date.getTime() - (date.getTime() % INTERVAL) +
TZ_ADJ);
eds.currentTimestampString =

eds.currentTimestampFormat.format(eds.currentTimestamp);
}

You will have to set the value of TZ_ADJ to be 5hrs, or you could
compute it from TimeZone.getDefault(). Note that it won't adjust for
DST or anything like that. I'm not sure if that's a problem for you.

I'm curious... what's wrong with GMT?

- -chris

> On Thu, Dec 15, 2016 at 3:31 AM, Konstantin Kolinko
>  wrote:
> 
>> 2016-12-14 18:48 GMT+03:00 Farhan Tariq
>> :
>>> Hello team,
>>> 
>>> I am not sure why the timezone is explicitly set to GMT in 
>>> ExtendedAccessLogValve class? To capture URL encoded parameters
>>> I looking to use this class but need
>> help
>>> to get time in GMT+5. I am using tomcat 7 on redhat. Any
>>> suggestions?
>> 
>> 
>> 1. Please read the mailing list rules: 
>> http://tomcat.apache.org/lists.html#tomcat-users
>> 
>> You have not mentioned what exact version of Tomcat you are using
>> (1.)
>> 
>> 2. Use of GMT in ExtendedAccessLogValve is by design.
>> 
>> That valve implements log format specified by "Extended Log File 
>> Format" specification by W3C, and the specification dictates that
>> the time is in GMT.
>> 
>> http://tomcat.apache.org/tomcat-8.5-doc/config/valve. 
>> html#Extended_Access_Log_Valve
>> 
>> https://www.w3.org/TR/WD-logfile.html
>> 
>> 
>> It may be good to implement configurable timezone in
>> AccessLogValve (currently it uses TimeZone.getDefault()), but I
>> think that ExtendedAccessLogValve shall remain with GMT.
>> 
>> Best regards, Konstantin Kolinko
>> 
>> -
>>
>> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
>> 
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYhiNaAAoJEBzwKT+lPKRYaIIQAJGxF3VN5tfrgtAiAVRHrbCx
wAlmCqqLQ/KpFTxh8JQiDFzmjvjGR8HXfZO9G1RkVAl5VcVWQ8RK6jizVaS21Wfi
BU5XFWiEz2goV9WpoJF12PUrrUKrvZzMo/n9QIXdWsD/wVFbXnUHPYKhhvIHx8uF
TZJRlB2Wav2oCw0gYNG5yMf/B/2afjptonZux3EUWAZHnKzZzvn9+PKVXHcRUWFj
ovtoCTG0NbRKAHphqFIHyL45V27JnkT14XGn8bhBdIQLhifhWfJVtu70HbBluol8
f80JPMNfB3wTzm+4QTMqTa4ZCYQrrA/s2LPicWJ4vKz0r52jnyKGoPDJKT7oQjEn
/ipBO20kH8PGxBjU64wbCEV1KEyCYq1+b/mnlX98KFJudNd4jk30pXAUuxhP2PHv

Re: Tomcat maintainer's ApacheCon NA presentation

[Coty Sutherland]

Hi Emmanuel,

Thanks for the input and I'm glad the idea is so being well received.
I'd love for you to share some slides with me on the Debian/Ubuntu
distribution as I have very limited experience with them and tomcat
(I've used Raspbian and Kali a good bit, but mostly use Fedora) :)
Also if you have any resources that you can point me to to help me
learn about tomcat on those distros that would help me better support
users in #tomcat on freenode (I get a good amount of distro-specific
questions there).



Thanks again!

On Mon, Jan 23, 2017 at 4:08 AM, Emmanuel Bourg  wrote:
> Hi Coty,
>
> This is an excellent idea. I won't be able to attend ApacheCon NA but
> I'll be happy to provide some input for your presentation and contribute
> a few slides to describe the Tomcat packaging in Debian/Ubuntu.
>
> Emmanuel Bourg
>
> Le 19/01/2017 à 19:26, Coty Sutherland a écrit :
>> Hi all,
>>
>> My name is Coty and I'm the maintainer for RHEL tomcat and a
>> co-maintainer for Fedora/EPEL tomcat. I'm reaching out to you all in
>> response to the tomcat users list thread (subject: TomcatCon @
>> ApacheCon) to see if you're interested in doing a talk with me about
>> linux packaging at the upcoming ApacheCon NA conference. Is anyone
>> interested? Do you know any of the maintainers for other linux
>> distributions that may be interested?
>>
>> As far as the talk goes, I figure it could be a panel discussion; we
>> can take some topics/slides on how each distro packages tomcat
>> differently and why we do that, then get the audience engaged to
>> solicit some feedback on how we can better provide tomcat in our
>> respective distros. We could also use this as a forum to bring up
>> tomcat backwards compatibility issues, as I've gotten lots of
>> complaints about that in the past :( The other tomcat committers seem
>> to be pretty open to these discussions, so I'd love to include other
>> distros in the conversation to get all the different perspectives we
>> can.
>>
>>
>>
>> Thanks!
>> Coty
>>
>

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

Re: Stopping any Tomcat thread running more than an amount of time

[tomcat]

On 23.01.2017 13:41, Abdessamed Mansouri wrote:

Hello, Thank you for your answers, we are integratting JSF (Mojarra) and
using it, so in many cases, in the same page there's some functionnalities
which work and other not, there's also some functionnalities which work
with a little data (reasonable time) but with a little larger data take too
much time because of bad implementation and i have fear to say that we
really don't know all,the functionnalities which dont work (takes too much
time).

We think this is the only (not necessary) temporary solution.

Thank you all.


Hi. Apart from the suggestions below, I don't think that there is anything "out of the 
box" which does the kind of thing you want.

So you might have to write this yourself.
I am not really an expert, but in terms of architecture this might be a job for a "servlet 
filter", which starts a timer before forwarding the call to the real application.
How the filter would have to react, when it is called by the timer after 5 minutes, in 
order to "kill" the running servlet and return an informative response to the caller, is 
beyond me though, specially without modifying the servlet itself.

Generating an exception and catching it in the response part of the filter ?




2017-01-23 12:43 GMT+01:00 André Warnier (tomcat) :


On 23.01.2017 12:37, Aurélien Terrestris wrote:


Hello,

if it is possible to know which servlet is involved in this problem, maybe
could you update the web.xml and deactivate this servlet by commenting its
servlet mapping. You would then get 404 errors, but maybe it's better than
your problem now.

regards
A.T.



I suppose that you could also, instead, map these servlets to some nice
static html page, with a message telling the user that it is disabled, and
ask them to use the "back" button to return to the previous page.




2017-01-23 12:01 GMT+01:00 Abdessamed Mansouri :

Hello all,


We have an application which turns on Tomcat and suffer from bad
performance (we are trying to find a solution by reimplementing it), so
there's many many many simple functionnalities which take too much time
(bad implementation) sometimes up to 30mins (and to hours), so our
client's
employees dont use these functionnalities but sometimes by mistake they
run
some of it which make all the entire server slow for all other employees
because the tomcat request handler threads still turning in background,
so
temporarily we are seeking for a way (through config or code hacking) to
let Tomcat stops it's threads after some amout of time if they didn't
completed, for exemple : Tomcat will stop any of its running thread
after 5
mins if the thread doesn't completed.

Tomcat version : 7.0.35

Thanks

--
Abdessamed MANSOURI
Consultant développeur en nouvelles technologies - ALTI Algérie
Lot N° 30 – Lotissement 20 août 1955 – Oued Romane – EL Achour – 16106 –
Alger
Tél 1 : 06 73 37 72 58
Tél 2 : 05 56 66 57 56
Email : amanso...@alti-dz.com






-
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: Stopping any Tomcat thread running more than an amount of time

[Abdessamed Mansouri]

Hello, Thank you for your answers, we are integratting JSF (Mojarra) and
using it, so in many cases, in the same page there's some functionnalities
which work and other not, there's also some functionnalities which work
with a little data (reasonable time) but with a little larger data take too
much time because of bad implementation and i have fear to say that we
really don't know all,the functionnalities which dont work (takes too much
time).

We think this is the only (not necessary) temporary solution.

Thank you all.

2017-01-23 12:43 GMT+01:00 André Warnier (tomcat) :

> On 23.01.2017 12:37, Aurélien Terrestris wrote:
>
>> Hello,
>>
>> if it is possible to know which servlet is involved in this problem, maybe
>> could you update the web.xml and deactivate this servlet by commenting its
>> servlet mapping. You would then get 404 errors, but maybe it's better than
>> your problem now.
>>
>> regards
>> A.T.
>>
>
> I suppose that you could also, instead, map these servlets to some nice
> static html page, with a message telling the user that it is disabled, and
> ask them to use the "back" button to return to the previous page.
>
>
>>
>> 2017-01-23 12:01 GMT+01:00 Abdessamed Mansouri :
>>
>> Hello all,
>>>
>>> We have an application which turns on Tomcat and suffer from bad
>>> performance (we are trying to find a solution by reimplementing it), so
>>> there's many many many simple functionnalities which take too much time
>>> (bad implementation) sometimes up to 30mins (and to hours), so our
>>> client's
>>> employees dont use these functionnalities but sometimes by mistake they
>>> run
>>> some of it which make all the entire server slow for all other employees
>>> because the tomcat request handler threads still turning in background,
>>> so
>>> temporarily we are seeking for a way (through config or code hacking) to
>>> let Tomcat stops it's threads after some amout of time if they didn't
>>> completed, for exemple : Tomcat will stop any of its running thread
>>> after 5
>>> mins if the thread doesn't completed.
>>>
>>> Tomcat version : 7.0.35
>>>
>>> Thanks
>>>
>>> --
>>> Abdessamed MANSOURI
>>> Consultant développeur en nouvelles technologies - ALTI Algérie
>>> Lot N° 30 – Lotissement 20 août 1955 – Oued Romane – EL Achour – 16106 –
>>> Alger
>>> Tél 1 : 06 73 37 72 58
>>> Tél 2 : 05 56 66 57 56
>>> Email : amanso...@alti-dz.com
>>>
>>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
Abdessamed MANSOURI
Consultant développeur en nouvelles technologies - ALTI Algérie
Lot N° 30 – Lotissement 20 août 1955 – Oued Romane – EL Achour – 16106 –
Alger
Tél 1 : 06 73 37 72 58
Tél 2 : 05 56 66 57 56
Email : amanso...@alti-dz.com

AW: https redirect failed for POST request when behind a load balancer

[Kreuser, Peter]

Bin,

> Peter:
> Our Load balancer uses a VIP to do the redirect, so when a request coming in 
> as http://lb-api:8080, it changes it into https://lb-api:8443 and submit to 
> the api server behind. I could not see any redirect logged into the access 
> log. However, if I submit a request to the api server directly using 
> http://my-api:8080, I'd see a redirect return code of 302 and another entry 
> after that with the request to port 8443. Almost make me thing it might be 
> the load balancer that is redirecting the POST request to a GET. Is that 
> possible?
> 
> Thank you again,

The redirect takes place in the client. What kind of client do you use? Could 
you send us the response headers from the two setups?

You did not answer on my recommendation to fix the app to be https from the 
start. In that case the redirect will be unnecessary...

Peter

> 
> Bin
> 
> -Original Message-
> From: Kreuser, Peter [mailto:pkreu...@airplus.com] 
> Sent: Friday, January 20, 2017 1:43 AM
> To: Tomcat Users List 
> Subject: AW: https redirect failed for POST request when behind a load 
> balancer
> 
> Hi Bin
> 
> 
> 
> I wonder if the redirect will use a 301 or 302 and that per default results 
> in a GET. How is this implemented in the loadbalancer?
> 
> 
> As I read a 307 should preserve the request method. From: 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__stackoverflow.com_questions_13628831_apache-2D301-2Dredirect-2Dand-2Dpreserving-2Dpost-2Ddata=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=T34XNMuHs99f3YkStEdBgUp9XTcpTRir8U9GVk2H5hQ=quLXN4mLB8a4NNSXBq_y8iftNygJUC3ZqeL5gYH46So=Cr-WfGYAinyNBtKqFUGgzoXRehN9Mfw-Ssq2Q24Hpvk=
>   
> 
> 
> 
> If you want to enforce the redirect to https, you should however consider a 
> different approach.
> 
> 
> 
> If it is necessary to protect the data, no POST should ever go to http/port 
> 8080, as the data will be open in the first request.
> 
> So in my opinion the calling website/application that is sending the data to 
> 8080 should be modified in the first place.
> 
> 
> 
> Best regards
> 
> 
> 
> Peter 
> 
> 
> 
> > -Original Message-
> 
> > From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] 
> 
> > Sent: Wednesday, January 18, 2017 11:43 PM
> 
> > To: Tomcat Users List 
> 
> > Subject: Re: https redirect failed for POST request when behind a load 
> > balancer
> 
> > 
> 
> > 1. You know that "api-lb" and "lb-api" above are two different host names?
> 
> > 
> 
> > 2. What HTTP response code is send to client to perform the redirection?
> 
> > (What is displayed by access log? Or by "network" monitoring tool in 
> > browser.  What are actual responses to perform the redirection).
> 
> > 
> 
> > Some response codes used for redirects allow the browser to change POST to 
> > GET, some do not. See the HTTP protocol specification for details.
> 
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.apache.org_tomcat_Specifications=DwIFaQ=uilaK90D4TOVoH58JNXRgQ=T34XNMuHs99f3YkStEdBgUp9XTcpTRir8U9GVk2H5hQ=g9XvhdAG4g80Ajw7i4CvF3kysWtESxDF6NFX8j630c8=mOjl8_uOfuo3lfn8xDS6jwCZao9az7SjXLxgAh-2Twc=
> >  
> 
> > 
> 
> > Is redirect performed by a single response, or there are several redirect 
> > responses in a chain, A -> B -> C/ ?
> 
> > 
> 
> > 3. Actual configuration?
> 
> > 
> 
> > (For someone else to reproduce the issue or to match your tale to their 
> > configs).
> 
> > 
> 
> > Best regards,
> 
> > Konstantin Kolinko
> 
> > 
> 
> > -
> 
> > 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: Stopping any Tomcat thread running more than an amount of time

[tomcat]

On 23.01.2017 12:37, Aurélien Terrestris wrote:

Hello,

if it is possible to know which servlet is involved in this problem, maybe
could you update the web.xml and deactivate this servlet by commenting its
servlet mapping. You would then get 404 errors, but maybe it's better than
your problem now.

regards
A.T.


I suppose that you could also, instead, map these servlets to some nice static html page, 
with a message telling the user that it is disabled, and ask them to use the "back" button 
to return to the previous page.





2017-01-23 12:01 GMT+01:00 Abdessamed Mansouri :


Hello all,

We have an application which turns on Tomcat and suffer from bad
performance (we are trying to find a solution by reimplementing it), so
there's many many many simple functionnalities which take too much time
(bad implementation) sometimes up to 30mins (and to hours), so our client's
employees dont use these functionnalities but sometimes by mistake they run
some of it which make all the entire server slow for all other employees
because the tomcat request handler threads still turning in background, so
temporarily we are seeking for a way (through config or code hacking) to
let Tomcat stops it's threads after some amout of time if they didn't
completed, for exemple : Tomcat will stop any of its running thread after 5
mins if the thread doesn't completed.

Tomcat version : 7.0.35

Thanks

--
Abdessamed MANSOURI
Consultant développeur en nouvelles technologies - ALTI Algérie
Lot N° 30 – Lotissement 20 août 1955 – Oued Romane – EL Achour – 16106 –
Alger
Tél 1 : 06 73 37 72 58
Tél 2 : 05 56 66 57 56
Email : amanso...@alti-dz.com






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

Re: Stopping any Tomcat thread running more than an amount of time

[Aurélien Terrestris]

Hello,

if it is possible to know which servlet is involved in this problem, maybe
could you update the web.xml and deactivate this servlet by commenting its
servlet mapping. You would then get 404 errors, but maybe it's better than
your problem now.

regards
A.T.


2017-01-23 12:01 GMT+01:00 Abdessamed Mansouri :

> Hello all,
>
> We have an application which turns on Tomcat and suffer from bad
> performance (we are trying to find a solution by reimplementing it), so
> there's many many many simple functionnalities which take too much time
> (bad implementation) sometimes up to 30mins (and to hours), so our client's
> employees dont use these functionnalities but sometimes by mistake they run
> some of it which make all the entire server slow for all other employees
> because the tomcat request handler threads still turning in background, so
> temporarily we are seeking for a way (through config or code hacking) to
> let Tomcat stops it's threads after some amout of time if they didn't
> completed, for exemple : Tomcat will stop any of its running thread after 5
> mins if the thread doesn't completed.
>
> Tomcat version : 7.0.35
>
> Thanks
>
> --
> Abdessamed MANSOURI
> Consultant développeur en nouvelles technologies - ALTI Algérie
> Lot N° 30 – Lotissement 20 août 1955 – Oued Romane – EL Achour – 16106 –
> Alger
> Tél 1 : 06 73 37 72 58
> Tél 2 : 05 56 66 57 56
> Email : amanso...@alti-dz.com
>

Stopping any Tomcat thread running more than an amount of time

[Abdessamed Mansouri]

Hello all,

We have an application which turns on Tomcat and suffer from bad
performance (we are trying to find a solution by reimplementing it), so
there's many many many simple functionnalities which take too much time
(bad implementation) sometimes up to 30mins (and to hours), so our client's
employees dont use these functionnalities but sometimes by mistake they run
some of it which make all the entire server slow for all other employees
because the tomcat request handler threads still turning in background, so
temporarily we are seeking for a way (through config or code hacking) to
let Tomcat stops it's threads after some amout of time if they didn't
completed, for exemple : Tomcat will stop any of its running thread after 5
mins if the thread doesn't completed.

Tomcat version : 7.0.35

Thanks

-- 
Abdessamed MANSOURI
Consultant développeur en nouvelles technologies - ALTI Algérie
Lot N° 30 – Lotissement 20 août 1955 – Oued Romane – EL Achour – 16106 –
Alger
Tél 1 : 06 73 37 72 58
Tél 2 : 05 56 66 57 56
Email : amanso...@alti-dz.com

Re: Tomcat maintainer's ApacheCon NA presentation

[Emmanuel Bourg]

Hi Coty,

This is an excellent idea. I won't be able to attend ApacheCon NA but
I'll be happy to provide some input for your presentation and contribute
a few slides to describe the Tomcat packaging in Debian/Ubuntu.

Emmanuel Bourg

Le 19/01/2017 à 19:26, Coty Sutherland a écrit :
> Hi all,
> 
> My name is Coty and I'm the maintainer for RHEL tomcat and a
> co-maintainer for Fedora/EPEL tomcat. I'm reaching out to you all in
> response to the tomcat users list thread (subject: TomcatCon @
> ApacheCon) to see if you're interested in doing a talk with me about
> linux packaging at the upcoming ApacheCon NA conference. Is anyone
> interested? Do you know any of the maintainers for other linux
> distributions that may be interested?
> 
> As far as the talk goes, I figure it could be a panel discussion; we
> can take some topics/slides on how each distro packages tomcat
> differently and why we do that, then get the audience engaged to
> solicit some feedback on how we can better provide tomcat in our
> respective distros. We could also use this as a forum to bring up
> tomcat backwards compatibility issues, as I've gotten lots of
> complaints about that in the past :( The other tomcat committers seem
> to be pretty open to these discussions, so I'd love to include other
> distros in the conversation to get all the different perspectives we
> can.
> 
> 
> 
> Thanks!
> Coty
> 


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