Re: One more servlet reverse proxy solution to the wiki

2017-01-27 Thread Woonsan Ko 
On Fri, Jan 27, 2017 at 2:57 PM, Mark Thomas  wrote:
> On 27/01/2017 18:29, Woonsan Ko wrote:
>> Hi,
>>
>> Recently I've noticed from another thread that the following wiki page
>> has a list of servlet based reverse proxy solutions:
>> - https://wiki.apache.org/tomcat/ServletProxy
>>
>> I know of another solution:
>> - 
>> http://portals.apache.org/applications/webcontent2/reverse-proxy-module.html
>>
>> Could someone add that info into the wiki page?
>
> Sure. You can. :)
>
> Create yourself and account, let us know your user name and we'll grant
> you edit karma.

Thanks, Mark!
My username is 'WoonsanKo'.

Woonsan

>
> Mark
>
>
>> Here's my summary about the solution:
>>
>>  4) Apache Portals WebContent-2 Reverse Proxy Module : The Reverse
>> Proxy Module provides the features of Reverse Proxy, and it consists
>> of HTTP Client builder components (using HttpClient 4), Reverse Proxy
>> Command/Chain components (using Apache Commons Chain), and Reverse
>> Proxy Servlets and Filters.
>> With this Reverse Proxy Module, you can configure proxy mappings
>> with YAML configuration, you can rewrite content using built-in
>> content rewriting components, and you can even customize the
>> processing commands in the chain easily.
>> This module is part of WebContent-2 portlet web application
>> project, but the reverse proxy jar module has been designed and
>> working in normal servlet (non-portlet) environments independently as
>> well. See 
>> http://portals.apache.org/applications/webcontent2/modules-overview.html
>> for detail.
>>
>> Link: 
>> http://portals.apache.org/applications/webcontent2/reverse-proxy-module.html
>>
>>
>> Thanks in advance,
>>
>> Woonsan
>>
>> -
>> 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
>

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

Re: One more servlet reverse proxy solution to the wiki

2017-01-27 Thread Mark Thomas 
On 27/01/2017 18:29, Woonsan Ko wrote:
> Hi,
> 
> Recently I've noticed from another thread that the following wiki page
> has a list of servlet based reverse proxy solutions:
> - https://wiki.apache.org/tomcat/ServletProxy
> 
> I know of another solution:
> - http://portals.apache.org/applications/webcontent2/reverse-proxy-module.html
> 
> Could someone add that info into the wiki page?

Sure. You can. :)

Create yourself and account, let us know your user name and we'll grant
you edit karma.

Mark


> Here's my summary about the solution:
> 
>  4) Apache Portals WebContent-2 Reverse Proxy Module : The Reverse
> Proxy Module provides the features of Reverse Proxy, and it consists
> of HTTP Client builder components (using HttpClient 4), Reverse Proxy
> Command/Chain components (using Apache Commons Chain), and Reverse
> Proxy Servlets and Filters.
> With this Reverse Proxy Module, you can configure proxy mappings
> with YAML configuration, you can rewrite content using built-in
> content rewriting components, and you can even customize the
> processing commands in the chain easily.
> This module is part of WebContent-2 portlet web application
> project, but the reverse proxy jar module has been designed and
> working in normal servlet (non-portlet) environments independently as
> well. See 
> http://portals.apache.org/applications/webcontent2/modules-overview.html
> for detail.
> 
> Link: 
> http://portals.apache.org/applications/webcontent2/reverse-proxy-module.html
> 
> 
> Thanks in advance,
> 
> Woonsan
> 
> -
> 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: Apache Tomcat/7.0.39 crashed with fatal error

2017-01-27 Thread Coty Sutherland 
> # Problematic frame:
> # J  
> org.apache.http.impl.cookie.BestMatchSpec.formatCookies(Ljava/util/List;)Ljava/util/List;

Generally a crash in a java frame is a JVM bug. A quick google search
of the problematic frame yields the following first result,
https://github.com/rholder/jvm-loop-unswitching-bug. Looking at the
java7 bug linked on the page
(http://bugs.java.com/view_bug.do?bug_id=8025398) and further details
from the bug that the fix was backported from
(http://bugs.java.com/view_bug.do?bug_id=8021898) shows evidence that
this is likely your issue. You'll need to update your JDK or use the
suggested workaround to prevent future occurrences.

On Thu, Jan 26, 2017 at 4:40 PM, Christopher Schultz
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Aurélien,
>
> On 1/26/17 4:31 PM, Aurélien Terrestris wrote:
>> maybe you're just sending cookies with non-compliant characters.
>> Please check what you're sending if you can reproduce this problem
>> yourself
>>
>> RFC 6265 says  :
>>
>> cookie-value  = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
>> cookie-octet  = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E ;
>> US-ASCII characters excluding CTLs, ; whitespace DQUOTE, comma,
>> semicolon, ; and backslash
>
> Even if the client is sending a malformed HTTP header (or cookie,
> specifically), it shouldn't crash the JVM.
>
> - -chris
>
>> 2017-01-26 22:22 GMT+01:00 Satish Chhatpar 02
>> :
>>
>>> Yes all of them failed in the same way.
>>>
>>>
>>> # Problematic frame: # J
>>> org.apache.http.impl.cookie.BestMatchSpec.formatCookies(
>>> Ljava/util/List;)Ljava/util/List;
>>>
>>>
>>>
>>> Regards
>>>
>>> Satish Chhatpar
>>>
>>>
>>>  From: Christopher Schultz
>>>  Sent: Friday, January 27, 2017
>>> 2:44:54 AM To: Tomcat Users List Subject: Re: Apache
>>> Tomcat/7.0.39 crashed with fatal error
>>>
>> Satish,
>>
>> On 1/26/17 3:42 PM, Satish Chhatpar 02 wrote:
> Thanks Chris. I appreciate your help.
>
> All 4 tomcats are on diff machines. One on each, with same
> tomcat version, same java version and same OS for all.
>>
>> Did they all fail in the same way (JVM crash @
>> org.apache.http.impl.cookie.BestMatchSpec.formatCookies)?
>>
> Tomcats are not in cluster.
>>
>> I would highly recommend upgrading the JVM on one of those servers
>> to 1.7.latest to see if everything still works. If things go well,
>>  upgrade all of them.
>>
>> Then deploy the 1.8.latest to one of them. Tomcat shouldn't have
>> any compatibility issues with Java 8, but you will definitely want
>> to test everything in your application of course.
>>
>> -chris
>>
>  From: Christopher Schultz
>  Sent: Friday, January 27, 2017
> 1:52:47 AM To: Tomcat Users List Subject: Re: Apache
> Tomcat/7.0.39 crashed with fatal error
>
> Satish,
>
> On 1/26/17 2:28 PM, Satish Chhatpar 02 wrote:
>> we are using Apache Tomcat/7.0.39 for our java
>> application.
>
> I highly recommend an upgrade for both Tomcat and Java.
> There are published vulnerabilities for both product versions
> you are using.
>
>> There are 4 tomcat instances using same tomcat version and
>> java version. yesterday all 4 tomcats crashed with below
>> error in hs_err_pid log file.
>
> All on the same hardware? Or separate machines?
>
>> This log file was created for all 4 tomcats.
>
>> Its very peculiar behaviour that all 4 crashed around same
>> time.
>
> If they are in a cluster, one going down could cause the
> load on the others to go up, increasing the chances of a
> problem.
>
>> Any information can help us to mitigate this incident.
>
>> Apache Tomcat/7.0.39
>
> Unless this is a package-managed version of Tomcat with an
> unfortunately inaccurate version number, that version of
> Tomcat is nearly 3 years old. The current version in the
> 7.0.x line is 7.0.75 (released yesterday).
>
>> java version "1.7.0_21" Java(TM) SE Runtime Environment
>> (build 1.7.0_21-b11) Java HotSpot(TM) 64-Bit Server VM
>> (build 23.21-b01, mixed mode)
>
> That version of Java is also nearly 3 years old. Latest 1.7
> build is 1.7.0_80 release nearly 3 years ago. Note that Java
> 7 is no longer supported unless you have a long-term support
> contract with Oracle, in which case the latest version is
> 1.7.0_131, released earlier this month.
>
>> OS used
>
>
>> Red Hat Enterprise Linux Server release 6.3 (Santiago)
>
> Ouch! 5 years old!
>
>> # # A fatal error has been detected by the Java Runtime
>> Environment: # #  SIGSEGV (0xb) at pc=0x7fed24ecfe9e,
>> pid=21352, tid=140656275650304 # # JRE version: 7.0_21-b11
>> # Java VM: Java HotSpot(TM) 64-Bit

Re: tomcat crashes with Java1.7

2017-01-27 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rejesh,

On 1/26/17 9:54 PM, Rajesh Cherukuri wrote:
> can some one help me on this , tomcat servers crashes if i use java
> 1.7 ir was running fine for more than an year

This sounds shockingly similar to this:

http://markmail.org/thread/iicz5xyeksaxxi54

- -chris

> # # A fatal error has been detected by the Java Runtime
> Environment: # #  SIGSEGV (0xb) at pc=0x7f1ff1018787,
> pid=13185, tid=139773910861568 # # JRE version: 7.0_21-b11 # Java
> VM: Java HotSpot(TM) 64-Bit Server VM (23.21-b01 mixed mode 
> linux-amd64 compressed oops) # Problematic frame: # J 
> org.apache.http.impl.cookie.BestMatchSpec.formatCookies(Ljava/util/Lis
t;)Ljava/util/List;
>
> 
#
> # Failed to write core dump. Core dumps have been disabled. To
> enable core dumping, try "ulimit -c unlimited" before starting Java
> again # # If you would like to submit a bug report, please visit: #
> http://bugreport.sun.com/bugreport/crash.jsp #
> 
> ---  T H R E A D  ---
> 
> Current thread (0x7f1fb426b000):  JavaThread "AD Thread
> Pool-Global25" daemon [_thread_in_Java, id=31406, 
> stack(0x7f1fa63e4000,0x7f1fa64e5000)]
> 
> siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), 
> si_addr=0x003f09db1aac
> 
> Registers: RAX=0x0007e1468c30, RBX=0x0004,
> RCX=0x003f09db1aa0, RDX=0x 
> RSP=0x7f1fa64e3010, RBP=0x0005,
> RSI=0x0007e13b6358, RDI=0x0007e13b6354 R8
> =0x0001, R9 =0x0001,
> R10=0x7fff, R11=0x 
> R12=0x, R13=0x00066ea4add8,
> R14=0x, R15=0x7f1fb426b000 
> RIP=0x7f1ff1018787, EFLAGS=0x00010202, 
> CSGSFS=0x0033, ERR=0x0004 
> TRAPNO=0x000e
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYi5UQAAoJEBzwKT+lPKRYOdUP/RFsHGGNHTBaxt0QF2TNSqlm
eh3mXDwM5EzBb3oanS6AMzDS0MNnXLO/bZpbThMTRg0Vg9cSSCaew9qAr2P+c9wa
xUr+1OTbFyYqUoQaM++oGwxsWHgb7IbXWCvNzwhgXxb/V/VSUjoW20NcVOmRElIU
B53iwvPHERYREmRQdCaXIblqk/nGSZANDWC3dEZ6RvnnvtroIvOCbst1FD1oOweK
19hNdl1EBnSqB7w3rWjoepRi5Flv+Mpgd/hlmuaxOm5kapZgExS+Itd1YIwD9lUa
x7kcFrUrLDmuy0SWyq3wQCF9+35FYJ+JbsjsxhuBHCJsXpC8K8xxlXWhWl+rTllD
kxsbx21MnffKQ7aF7+/j6KNOP8F7paV2EK7m812RL8xoV9bGV/OoGPY1eSiWKFpr
34xFr7U9RzoDp0Th9FZTHWr1WJKHxeh83HudOb3E8k1bHWuxrG8f8Ava3tIM/ccV
NSMdS3OoozTrwJd1ZMd5dcNkbGjgZzuvWra69OZQOyksEC96k0//nOGj4yvkD4lE
CN0TYRAoo1ASo1a00R882FI2n0LhN4UeN2ZTgqjwaD8f8lXdcB/Hgqfa5pz3he4C
EjefDJywNaaKh8tOf0l8Hgc/b4ntHAskOaZII8WvSw+KcN4dp7VuUR7rsLTCnF8z
P0NUoMH2/nIGzd4BGIOn
=hsS1
-END PGP SIGNATURE-

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

One more servlet reverse proxy solution to the wiki

2017-01-27 Thread Woonsan Ko 
Hi,

Recently I've noticed from another thread that the following wiki page
has a list of servlet based reverse proxy solutions:
- https://wiki.apache.org/tomcat/ServletProxy

I know of another solution:
- http://portals.apache.org/applications/webcontent2/reverse-proxy-module.html

Could someone add that info into the wiki page?
Here's my summary about the solution:

 4) Apache Portals WebContent-2 Reverse Proxy Module : The Reverse
Proxy Module provides the features of Reverse Proxy, and it consists
of HTTP Client builder components (using HttpClient 4), Reverse Proxy
Command/Chain components (using Apache Commons Chain), and Reverse
Proxy Servlets and Filters.
With this Reverse Proxy Module, you can configure proxy mappings
with YAML configuration, you can rewrite content using built-in
content rewriting components, and you can even customize the
processing commands in the chain easily.
This module is part of WebContent-2 portlet web application
project, but the reverse proxy jar module has been designed and
working in normal servlet (non-portlet) environments independently as
well. See 
http://portals.apache.org/applications/webcontent2/modules-overview.html
for detail.

Link: 
http://portals.apache.org/applications/webcontent2/reverse-proxy-module.html


Thanks in advance,

Woonsan

-
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

2017-01-27 Thread Mark Thomas 
On 27/01/2017 08:24, Abdessamed Mansouri wrote:
> Thank you for your time and your suggestion and sorry for late response.
> 
> I don't know if that is possible in servlet filter, because we don't really
> want to kill the thread, we want only to stop it and return it to Tomcat
> thread pool for it be used again to handles new requests, so i think we
> should write a special thread pool which do that for us (that what is
> currently in my head).

Unless the long running code is going to respond to an interrupt in
timely manner, this is never going to work.

If the long running code will respond to an interrupt, a relatively
simple filter or valve that tracks in progress requests (it will need a
dedicated thread to periodically loop through the requests and interrupt
the ones running longer than the given threshold) will do the trick.

Mark


> 
> 2017-01-23 14:06 GMT+01:00 André Warnier (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
>>
>>
> 
> 


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

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

2017-01-27 Thread Abdessamed Mansouri 
Thank you for your time and your suggestion and sorry for late response.

I don't know if that is possible in servlet filter, because we don't really
want to kill the thread, we want only to stop it and return it to Tomcat
thread pool for it be used again to handles new requests, so i think we
should write a special thread pool which do that for us (that what is
currently in my head).

2017-01-23 14:06 GMT+01:00 André Warnier (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
>
>


-- 
Abdessamed MANSOURI
Consultant développeur en nouvelles technologies – ALTI Algérie
Lotissement les piètes – N° 06 Rue B les crêtes Hydra – 16016 – Alger
Tél 1 : 06 73 37 72 58
Tél 2 : 05 56 66 57 56
Email : amanso...@alti-dz.com