You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Christian Dutaret <cd...@gmail.com> on 2007/10/23 18:43:49 UTC
T4.1.3 : 100% CPU usage on tomcat due to server-side email validation
Hi all,
Occasionally, my T4.1.3 application running on tomcat/jdk5/linux gets to
take 100% CPU and then never release it until I restart the JVM. Doesn't
happen too often, maybe 5 times in a few months. After I restart Tomcat,
everything goes back to normal.
I eventually decided to try to find out the suspected infinite loop that
causes all this. So I did a thread dump on the JVM, identified the
cpu-consuming threads. I found 3 threads wasting 33% of the CPU each, and
according to the thread dump, they're all running infinite loops on regexp
matching. Here is an extract of the thread dump for one of these threads :
at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
at java.util.regex.Pattern$Loop.matchInit(Pattern.java:4721)
at java.util.regex.Pattern$Prolog.match(Pattern.java:4658)
at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
at java.util.regex.Pattern$Begin.match(Pattern.java:3084)
at java.util.regex.Matcher.match(Matcher.java:1114)
at java.util.regex.Matcher.matches(Matcher.java:495)
at org.apache.tapestry.util.RegexpMatcher.matches(RegexpMatcher.java
:71)
at org.apache.tapestry.form.validator.Email.validate(Email.java:61)
at org.apache.tapestry.form.ValidatableFieldSupportImpl.validate(
ValidatableFieldSupportImpl.java:99)
at
$ValidatableFieldSupport_115c315e3ad.validate($ValidatableFieldSupport_115c315e3ad.java)
at org.apache.tapestry.form.TextField.rewindFormComponent(
TextField.java:103)
As you can see, it seems that the email validator regexp matching causes an
infinite loop in some rare cases. Unfortunately, I am not able to retrieve
which values did cause this.
In the mean time, I'll try my own simpler regexp, or maybe I'll just skip
email validation until I get a better idea.
Thanks for any hint on this
Ch.
Re: T4.1.3 : 100% CPU usage on tomcat due to server-side email validation
Posted by Ulrich Stärk <ul...@spielviel.de>.
You are right, that pattern is not doing what it's supposed to do. I
reopened the issue and attached a new patch.
And email addresses containing an underscore are allowed. I put that
into the patch too.
Uli
Christian Dutaret schrieb:
> Seems there is a bug in the new pattern:
> public static final String USERNAME_PATTERN =
> "([\\\\da-z]+[-._+&'])*[\\\\da-z]+";
>
> should be:
> public static final String USERNAME_PATTERN =
> "([\\da-z]+[-._+&'])*[\\da-z]+";
> or:
> public static final String USERNAME_PATTERN =
> "([0-9a-z]+[-._+&'])*[0-9a-z]+";
>
> Additionally, are email addresses like user_@example.com allowed by the RFC?
> They are allowed by some mail providers, I actually own one such address.
>
> Ch.
>
>
> 2007/10/24, Ulrich Stärk <ul...@spielviel.de>:
>> GMT +1
>>
>> Uli
>>
>> Christian Dutaret schrieb:
>>> Thx for the swift fix. I've patched my code to use the suggested new
>>> validator instead of the previous one (I've copied the one that was
>>> committed earlier today). I'll let you know if any new problem arise.
>>>
>>> (seems this was a short night sleep for both of you guys, or is it some
>> time
>>> zone illusion?)
>>>
>>> Thx again
>>> Ch.
>>>
>>> 2007/10/24, andyhot <an...@di.uoa.gr>:
>>>> thx for all - i'll see if i can have the test do performance check,
>>>> and commit asap
>>>>
>>>> Ulrich Stärk wrote:
>>>>> I Just created a JIRA report and a fix for that problem.
>>>>> https://issues.apache.org/jira/browse/TAPESTRY-1857
>>>>>
>>>>> Uli
>>>>>
>>>>> Ulrich Stärk schrieb:
>>>>>> I just came to the same conclusion. The problem is with the
>>>>>> ([-_\\.]*[A-Za-z0-9]+)* part of the regexp in the user as well as the
>>>>>> domain part. Apart from that this regexp will reject email addresses
>>>>>> which are valid according to RFC 3696 like foo+bar@example.com
>>>>>>
>>>>>> Uli
>>>>>>
>>>>>> andyhot schrieb:
>>>>>>> hmmm - nice report - looks like that specific email regex is
>>>>>>> problematic when
>>>>>>> the given string is not email and contains lots of chars (>25-30
>>>>>>> result in more than 100000 iterations
>>>>>>> according to RegexBuddy) - we'll probably have to find a better
>>>>>>> regex i guess
>>>>>>>
>>>>>>> http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html looks quite
>>>>>>> interesting though ;)
>>>>>>>
>>>>>>> Christian Dutaret wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> Occasionally, my T4.1.3 application running on tomcat/jdk5/linux
>>>>>>>> gets to
>>>>>>>> take 100% CPU and then never release it until I restart the JVM.
>>>>>>>> Doesn't
>>>>>>>> happen too often, maybe 5 times in a few months. After I restart
>>>>>>>> Tomcat,
>>>>>>>> everything goes back to normal.
>>>>>>>> I eventually decided to try to find out the suspected infinite loop
>>>>>>>> that
>>>>>>>> causes all this. So I did a thread dump on the JVM, identified the
>>>>>>>> cpu-consuming threads. I found 3 threads wasting 33% of the CPU
>>>>>>>> each, and
>>>>>>>> according to the thread dump, they're all running infinite loops on
>>>>>>>> regexp
>>>>>>>> matching. Here is an extract of the thread dump for one of these
>>>>>>>> threads :
>>>>>>>>
>>>>>>>> at java.util.regex.Pattern$GroupTail.match(Pattern.java
>> :4634)
>>>>>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>>>>>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>>>>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
>>>>>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>>>>>>> at java.util.regex.Pattern$GroupHead.match(Pattern.java
>> :4575)
>>>>>>>> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
>>>>>>>> at java.util.regex.Pattern$GroupTail.match(Pattern.java
>> :4634)
>>>>>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>>>>>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>>>>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
>>>>>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>>>>>>> at java.util.regex.Pattern$GroupHead.match(Pattern.java
>> :4575)
>>>>>>>> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
>>>>>>>> at java.util.regex.Pattern$GroupTail.match(Pattern.java
>> :4634)
>>>>>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>>>>>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>>>>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
>>>>>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>>>>>>> at java.util.regex.Pattern$GroupHead.match(Pattern.java
>> :4575)
>>>>>>>> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
>>>>>>>> at java.util.regex.Pattern$GroupTail.match(Pattern.java
>> :4634)
>>>>>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>>>>>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>>>>>>> at java.util.regex.Pattern$GroupHead.match(Pattern.java
>> :4575)
>>>>>>>> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
>>>>>>>> at java.util.regex.Pattern$GroupTail.match(Pattern.java
>> :4634)
>>>>>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>>>>>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>>>>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
>>>>>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>>>>>>> at java.util.regex.Pattern$GroupHead.match(Pattern.java
>> :4575)
>>>>>>>> at java.util.regex.Pattern$Loop.matchInit(Pattern.java
>> :4721)
>>>>>>>> at java.util.regex.Pattern$Prolog.match(Pattern.java:4658)
>>>>>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>>>>>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>>>>>>> at java.util.regex.Pattern$Begin.match(Pattern.java:3084)
>>>>>>>> at java.util.regex.Matcher.match(Matcher.java:1114)
>>>>>>>> at java.util.regex.Matcher.matches(Matcher.java:495)
>>>>>>>> at
>>>>>>>> org.apache.tapestry.util.RegexpMatcher.matches(RegexpMatcher.java
>>>>>>>> :71)
>>>>>>>> at
>>>>>>>> org.apache.tapestry.form.validator.Email.validate(Email.java:61)
>>>>>>>> at
>>>>>>>> org.apache.tapestry.form.ValidatableFieldSupportImpl.validate(
>>>>>>>> ValidatableFieldSupportImpl.java:99)
>>>>>>>> at
>>>>>>>>
>> $ValidatableFieldSupport_115c315e3ad.validate($ValidatableFieldSupport_115c315e3ad.java)
>>>>>>>> at org.apache.tapestry.form.TextField.rewindFormComponent(
>>>>>>>> TextField.java:103)
>>>>>>>>
>>>>>>>> As you can see, it seems that the email validator regexp matching
>>>>>>>> causes an
>>>>>>>> infinite loop in some rare cases. Unfortunately, I am not able to
>>>>>>>> retrieve
>>>>>>>> which values did cause this.
>>>>>>>>
>>>>>>>> In the mean time, I'll try my own simpler regexp, or maybe I'll
>>>>>>>> just skip
>>>>>>>> email validation until I get a better idea.
>>>>>>>>
>>>>>>>> Thanks for any hint on this
>>>>>>>>
>>>>>>>> Ch.
>>>>>>>>
>>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>>
>>>> --
>>>> Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
>>>> Tapestry / Tacos developer
>>>> Open Source / JEE Consulting
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T4.1.3 : 100% CPU usage on tomcat due to server-side email validation
Posted by Christian Dutaret <cd...@gmail.com>.
Seems there is a bug in the new pattern:
public static final String USERNAME_PATTERN =
"([\\\\da-z]+[-._+&'])*[\\\\da-z]+";
should be:
public static final String USERNAME_PATTERN =
"([\\da-z]+[-._+&'])*[\\da-z]+";
or:
public static final String USERNAME_PATTERN =
"([0-9a-z]+[-._+&'])*[0-9a-z]+";
Additionally, are email addresses like user_@example.com allowed by the RFC?
They are allowed by some mail providers, I actually own one such address.
Ch.
2007/10/24, Ulrich Stärk <ul...@spielviel.de>:
>
> GMT +1
>
> Uli
>
> Christian Dutaret schrieb:
> > Thx for the swift fix. I've patched my code to use the suggested new
> > validator instead of the previous one (I've copied the one that was
> > committed earlier today). I'll let you know if any new problem arise.
> >
> > (seems this was a short night sleep for both of you guys, or is it some
> time
> > zone illusion?)
> >
> > Thx again
> > Ch.
> >
> > 2007/10/24, andyhot <an...@di.uoa.gr>:
> >> thx for all - i'll see if i can have the test do performance check,
> >> and commit asap
> >>
> >> Ulrich Stärk wrote:
> >>> I Just created a JIRA report and a fix for that problem.
> >>> https://issues.apache.org/jira/browse/TAPESTRY-1857
> >>>
> >>> Uli
> >>>
> >>> Ulrich Stärk schrieb:
> >>>> I just came to the same conclusion. The problem is with the
> >>>> ([-_\\.]*[A-Za-z0-9]+)* part of the regexp in the user as well as the
> >>>> domain part. Apart from that this regexp will reject email addresses
> >>>> which are valid according to RFC 3696 like foo+bar@example.com
> >>>>
> >>>> Uli
> >>>>
> >>>> andyhot schrieb:
> >>>>> hmmm - nice report - looks like that specific email regex is
> >>>>> problematic when
> >>>>> the given string is not email and contains lots of chars (>25-30
> >>>>> result in more than 100000 iterations
> >>>>> according to RegexBuddy) - we'll probably have to find a better
> >>>>> regex i guess
> >>>>>
> >>>>> http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html looks quite
> >>>>> interesting though ;)
> >>>>>
> >>>>> Christian Dutaret wrote:
> >>>>>> Hi all,
> >>>>>>
> >>>>>> Occasionally, my T4.1.3 application running on tomcat/jdk5/linux
> >>>>>> gets to
> >>>>>> take 100% CPU and then never release it until I restart the JVM.
> >>>>>> Doesn't
> >>>>>> happen too often, maybe 5 times in a few months. After I restart
> >>>>>> Tomcat,
> >>>>>> everything goes back to normal.
> >>>>>> I eventually decided to try to find out the suspected infinite loop
> >>>>>> that
> >>>>>> causes all this. So I did a thread dump on the JVM, identified the
> >>>>>> cpu-consuming threads. I found 3 threads wasting 33% of the CPU
> >>>>>> each, and
> >>>>>> according to the thread dump, they're all running infinite loops on
> >>>>>> regexp
> >>>>>> matching. Here is an extract of the thread dump for one of these
> >>>>>> threads :
> >>>>>>
> >>>>>> at java.util.regex.Pattern$GroupTail.match(Pattern.java
> :4634)
> >>>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
> >>>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
> >>>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
> >>>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
> >>>>>> at java.util.regex.Pattern$GroupHead.match(Pattern.java
> :4575)
> >>>>>> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
> >>>>>> at java.util.regex.Pattern$GroupTail.match(Pattern.java
> :4634)
> >>>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
> >>>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
> >>>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
> >>>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
> >>>>>> at java.util.regex.Pattern$GroupHead.match(Pattern.java
> :4575)
> >>>>>> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
> >>>>>> at java.util.regex.Pattern$GroupTail.match(Pattern.java
> :4634)
> >>>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
> >>>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
> >>>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
> >>>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
> >>>>>> at java.util.regex.Pattern$GroupHead.match(Pattern.java
> :4575)
> >>>>>> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
> >>>>>> at java.util.regex.Pattern$GroupTail.match(Pattern.java
> :4634)
> >>>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
> >>>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
> >>>>>> at java.util.regex.Pattern$GroupHead.match(Pattern.java
> :4575)
> >>>>>> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
> >>>>>> at java.util.regex.Pattern$GroupTail.match(Pattern.java
> :4634)
> >>>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
> >>>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
> >>>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
> >>>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
> >>>>>> at java.util.regex.Pattern$GroupHead.match(Pattern.java
> :4575)
> >>>>>> at java.util.regex.Pattern$Loop.matchInit(Pattern.java
> :4721)
> >>>>>> at java.util.regex.Pattern$Prolog.match(Pattern.java:4658)
> >>>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
> >>>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
> >>>>>> at java.util.regex.Pattern$Begin.match(Pattern.java:3084)
> >>>>>> at java.util.regex.Matcher.match(Matcher.java:1114)
> >>>>>> at java.util.regex.Matcher.matches(Matcher.java:495)
> >>>>>> at
> >>>>>> org.apache.tapestry.util.RegexpMatcher.matches(RegexpMatcher.java
> >>>>>> :71)
> >>>>>> at
> >>>>>> org.apache.tapestry.form.validator.Email.validate(Email.java:61)
> >>>>>> at
> >>>>>> org.apache.tapestry.form.ValidatableFieldSupportImpl.validate(
> >>>>>> ValidatableFieldSupportImpl.java:99)
> >>>>>> at
> >>>>>>
> >>
> $ValidatableFieldSupport_115c315e3ad.validate($ValidatableFieldSupport_115c315e3ad.java)
> >>>>>> at org.apache.tapestry.form.TextField.rewindFormComponent(
> >>>>>> TextField.java:103)
> >>>>>>
> >>>>>> As you can see, it seems that the email validator regexp matching
> >>>>>> causes an
> >>>>>> infinite loop in some rare cases. Unfortunately, I am not able to
> >>>>>> retrieve
> >>>>>> which values did cause this.
> >>>>>>
> >>>>>> In the mean time, I'll try my own simpler regexp, or maybe I'll
> >>>>>> just skip
> >>>>>> email validation until I get a better idea.
> >>>>>>
> >>>>>> Thanks for any hint on this
> >>>>>>
> >>>>>> Ch.
> >>>>>>
> >>>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>
> >>>
> >> --
> >> Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
> >> Tapestry / Tacos developer
> >> Open Source / JEE Consulting
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: T4.1.3 : 100% CPU usage on tomcat due to server-side email validation
Posted by Ulrich Stärk <ul...@spielviel.de>.
GMT +1
Uli
Christian Dutaret schrieb:
> Thx for the swift fix. I've patched my code to use the suggested new
> validator instead of the previous one (I've copied the one that was
> committed earlier today). I'll let you know if any new problem arise.
>
> (seems this was a short night sleep for both of you guys, or is it some time
> zone illusion?)
>
> Thx again
> Ch.
>
> 2007/10/24, andyhot <an...@di.uoa.gr>:
>> thx for all - i'll see if i can have the test do performance check,
>> and commit asap
>>
>> Ulrich Stärk wrote:
>>> I Just created a JIRA report and a fix for that problem.
>>> https://issues.apache.org/jira/browse/TAPESTRY-1857
>>>
>>> Uli
>>>
>>> Ulrich Stärk schrieb:
>>>> I just came to the same conclusion. The problem is with the
>>>> ([-_\\.]*[A-Za-z0-9]+)* part of the regexp in the user as well as the
>>>> domain part. Apart from that this regexp will reject email addresses
>>>> which are valid according to RFC 3696 like foo+bar@example.com
>>>>
>>>> Uli
>>>>
>>>> andyhot schrieb:
>>>>> hmmm - nice report - looks like that specific email regex is
>>>>> problematic when
>>>>> the given string is not email and contains lots of chars (>25-30
>>>>> result in more than 100000 iterations
>>>>> according to RegexBuddy) - we'll probably have to find a better
>>>>> regex i guess
>>>>>
>>>>> http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html looks quite
>>>>> interesting though ;)
>>>>>
>>>>> Christian Dutaret wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Occasionally, my T4.1.3 application running on tomcat/jdk5/linux
>>>>>> gets to
>>>>>> take 100% CPU and then never release it until I restart the JVM.
>>>>>> Doesn't
>>>>>> happen too often, maybe 5 times in a few months. After I restart
>>>>>> Tomcat,
>>>>>> everything goes back to normal.
>>>>>> I eventually decided to try to find out the suspected infinite loop
>>>>>> that
>>>>>> causes all this. So I did a thread dump on the JVM, identified the
>>>>>> cpu-consuming threads. I found 3 threads wasting 33% of the CPU
>>>>>> each, and
>>>>>> according to the thread dump, they're all running infinite loops on
>>>>>> regexp
>>>>>> matching. Here is an extract of the thread dump for one of these
>>>>>> threads :
>>>>>>
>>>>>> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
>>>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>>>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
>>>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>>>>> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
>>>>>> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
>>>>>> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
>>>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>>>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
>>>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>>>>> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
>>>>>> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
>>>>>> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
>>>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>>>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
>>>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>>>>> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
>>>>>> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
>>>>>> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
>>>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>>>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>>>>> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
>>>>>> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
>>>>>> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
>>>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>>>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
>>>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>>>>> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
>>>>>> at java.util.regex.Pattern$Loop.matchInit(Pattern.java:4721)
>>>>>> at java.util.regex.Pattern$Prolog.match(Pattern.java:4658)
>>>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>>>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>>>>> at java.util.regex.Pattern$Begin.match(Pattern.java:3084)
>>>>>> at java.util.regex.Matcher.match(Matcher.java:1114)
>>>>>> at java.util.regex.Matcher.matches(Matcher.java:495)
>>>>>> at
>>>>>> org.apache.tapestry.util.RegexpMatcher.matches(RegexpMatcher.java
>>>>>> :71)
>>>>>> at
>>>>>> org.apache.tapestry.form.validator.Email.validate(Email.java:61)
>>>>>> at
>>>>>> org.apache.tapestry.form.ValidatableFieldSupportImpl.validate(
>>>>>> ValidatableFieldSupportImpl.java:99)
>>>>>> at
>>>>>>
>> $ValidatableFieldSupport_115c315e3ad.validate($ValidatableFieldSupport_115c315e3ad.java)
>>>>>> at org.apache.tapestry.form.TextField.rewindFormComponent(
>>>>>> TextField.java:103)
>>>>>>
>>>>>> As you can see, it seems that the email validator regexp matching
>>>>>> causes an
>>>>>> infinite loop in some rare cases. Unfortunately, I am not able to
>>>>>> retrieve
>>>>>> which values did cause this.
>>>>>>
>>>>>> In the mean time, I'll try my own simpler regexp, or maybe I'll
>>>>>> just skip
>>>>>> email validation until I get a better idea.
>>>>>>
>>>>>> Thanks for any hint on this
>>>>>>
>>>>>> Ch.
>>>>>>
>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>> --
>> Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
>> Tapestry / Tacos developer
>> Open Source / JEE Consulting
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T4.1.3 : 100% CPU usage on tomcat due to server-side email validation
Posted by Christian Dutaret <cd...@gmail.com>.
Thx for the swift fix. I've patched my code to use the suggested new
validator instead of the previous one (I've copied the one that was
committed earlier today). I'll let you know if any new problem arise.
(seems this was a short night sleep for both of you guys, or is it some time
zone illusion?)
Thx again
Ch.
2007/10/24, andyhot <an...@di.uoa.gr>:
>
> thx for all - i'll see if i can have the test do performance check,
> and commit asap
>
> Ulrich Stärk wrote:
> > I Just created a JIRA report and a fix for that problem.
> > https://issues.apache.org/jira/browse/TAPESTRY-1857
> >
> > Uli
> >
> > Ulrich Stärk schrieb:
> >> I just came to the same conclusion. The problem is with the
> >> ([-_\\.]*[A-Za-z0-9]+)* part of the regexp in the user as well as the
> >> domain part. Apart from that this regexp will reject email addresses
> >> which are valid according to RFC 3696 like foo+bar@example.com
> >>
> >> Uli
> >>
> >> andyhot schrieb:
> >>> hmmm - nice report - looks like that specific email regex is
> >>> problematic when
> >>> the given string is not email and contains lots of chars (>25-30
> >>> result in more than 100000 iterations
> >>> according to RegexBuddy) - we'll probably have to find a better
> >>> regex i guess
> >>>
> >>> http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html looks quite
> >>> interesting though ;)
> >>>
> >>> Christian Dutaret wrote:
> >>>> Hi all,
> >>>>
> >>>> Occasionally, my T4.1.3 application running on tomcat/jdk5/linux
> >>>> gets to
> >>>> take 100% CPU and then never release it until I restart the JVM.
> >>>> Doesn't
> >>>> happen too often, maybe 5 times in a few months. After I restart
> >>>> Tomcat,
> >>>> everything goes back to normal.
> >>>> I eventually decided to try to find out the suspected infinite loop
> >>>> that
> >>>> causes all this. So I did a thread dump on the JVM, identified the
> >>>> cpu-consuming threads. I found 3 threads wasting 33% of the CPU
> >>>> each, and
> >>>> according to the thread dump, they're all running infinite loops on
> >>>> regexp
> >>>> matching. Here is an extract of the thread dump for one of these
> >>>> threads :
> >>>>
> >>>> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
> >>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
> >>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
> >>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
> >>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
> >>>> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
> >>>> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
> >>>> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
> >>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
> >>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
> >>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
> >>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
> >>>> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
> >>>> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
> >>>> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
> >>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
> >>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
> >>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
> >>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
> >>>> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
> >>>> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
> >>>> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
> >>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
> >>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
> >>>> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
> >>>> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
> >>>> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
> >>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
> >>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
> >>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
> >>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
> >>>> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
> >>>> at java.util.regex.Pattern$Loop.matchInit(Pattern.java:4721)
> >>>> at java.util.regex.Pattern$Prolog.match(Pattern.java:4658)
> >>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
> >>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
> >>>> at java.util.regex.Pattern$Begin.match(Pattern.java:3084)
> >>>> at java.util.regex.Matcher.match(Matcher.java:1114)
> >>>> at java.util.regex.Matcher.matches(Matcher.java:495)
> >>>> at
> >>>> org.apache.tapestry.util.RegexpMatcher.matches(RegexpMatcher.java
> >>>> :71)
> >>>> at
> >>>> org.apache.tapestry.form.validator.Email.validate(Email.java:61)
> >>>> at
> >>>> org.apache.tapestry.form.ValidatableFieldSupportImpl.validate(
> >>>> ValidatableFieldSupportImpl.java:99)
> >>>> at
> >>>>
> $ValidatableFieldSupport_115c315e3ad.validate($ValidatableFieldSupport_115c315e3ad.java)
> >>>>
> >>>> at org.apache.tapestry.form.TextField.rewindFormComponent(
> >>>> TextField.java:103)
> >>>>
> >>>> As you can see, it seems that the email validator regexp matching
> >>>> causes an
> >>>> infinite loop in some rare cases. Unfortunately, I am not able to
> >>>> retrieve
> >>>> which values did cause this.
> >>>>
> >>>> In the mean time, I'll try my own simpler regexp, or maybe I'll
> >>>> just skip
> >>>> email validation until I get a better idea.
> >>>>
> >>>> Thanks for any hint on this
> >>>>
> >>>> Ch.
> >>>>
> >>>>
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
> --
> Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
> Tapestry / Tacos developer
> Open Source / JEE Consulting
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: T4.1.3 : 100% CPU usage on tomcat due to server-side email validation
Posted by andyhot <an...@di.uoa.gr>.
thx for all - i'll see if i can have the test do performance check,
and commit asap
Ulrich Stärk wrote:
> I Just created a JIRA report and a fix for that problem.
> https://issues.apache.org/jira/browse/TAPESTRY-1857
>
> Uli
>
> Ulrich Stärk schrieb:
>> I just came to the same conclusion. The problem is with the
>> ([-_\\.]*[A-Za-z0-9]+)* part of the regexp in the user as well as the
>> domain part. Apart from that this regexp will reject email addresses
>> which are valid according to RFC 3696 like foo+bar@example.com
>>
>> Uli
>>
>> andyhot schrieb:
>>> hmmm - nice report - looks like that specific email regex is
>>> problematic when
>>> the given string is not email and contains lots of chars (>25-30
>>> result in more than 100000 iterations
>>> according to RegexBuddy) - we'll probably have to find a better
>>> regex i guess
>>>
>>> http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html looks quite
>>> interesting though ;)
>>>
>>> Christian Dutaret wrote:
>>>> Hi all,
>>>>
>>>> Occasionally, my T4.1.3 application running on tomcat/jdk5/linux
>>>> gets to
>>>> take 100% CPU and then never release it until I restart the JVM.
>>>> Doesn't
>>>> happen too often, maybe 5 times in a few months. After I restart
>>>> Tomcat,
>>>> everything goes back to normal.
>>>> I eventually decided to try to find out the suspected infinite loop
>>>> that
>>>> causes all this. So I did a thread dump on the JVM, identified the
>>>> cpu-consuming threads. I found 3 threads wasting 33% of the CPU
>>>> each, and
>>>> according to the thread dump, they're all running infinite loops on
>>>> regexp
>>>> matching. Here is an extract of the thread dump for one of these
>>>> threads :
>>>>
>>>> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>>> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
>>>> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
>>>> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>>> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
>>>> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
>>>> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>>> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
>>>> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
>>>> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>>> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
>>>> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
>>>> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>>> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
>>>> at java.util.regex.Pattern$Loop.matchInit(Pattern.java:4721)
>>>> at java.util.regex.Pattern$Prolog.match(Pattern.java:4658)
>>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>>> at java.util.regex.Pattern$Begin.match(Pattern.java:3084)
>>>> at java.util.regex.Matcher.match(Matcher.java:1114)
>>>> at java.util.regex.Matcher.matches(Matcher.java:495)
>>>> at
>>>> org.apache.tapestry.util.RegexpMatcher.matches(RegexpMatcher.java
>>>> :71)
>>>> at
>>>> org.apache.tapestry.form.validator.Email.validate(Email.java:61)
>>>> at
>>>> org.apache.tapestry.form.ValidatableFieldSupportImpl.validate(
>>>> ValidatableFieldSupportImpl.java:99)
>>>> at
>>>> $ValidatableFieldSupport_115c315e3ad.validate($ValidatableFieldSupport_115c315e3ad.java)
>>>>
>>>> at org.apache.tapestry.form.TextField.rewindFormComponent(
>>>> TextField.java:103)
>>>>
>>>> As you can see, it seems that the email validator regexp matching
>>>> causes an
>>>> infinite loop in some rare cases. Unfortunately, I am not able to
>>>> retrieve
>>>> which values did cause this.
>>>>
>>>> In the mean time, I'll try my own simpler regexp, or maybe I'll
>>>> just skip
>>>> email validation until I get a better idea.
>>>>
>>>> Thanks for any hint on this
>>>>
>>>> Ch.
>>>>
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
Tapestry / Tacos developer
Open Source / JEE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T4.1.3 : 100% CPU usage on tomcat due to server-side email validation
Posted by Ulrich Stärk <ul...@spielviel.de>.
I Just created a JIRA report and a fix for that problem.
https://issues.apache.org/jira/browse/TAPESTRY-1857
Uli
Ulrich Stärk schrieb:
> I just came to the same conclusion. The problem is with the
> ([-_\\.]*[A-Za-z0-9]+)* part of the regexp in the user as well as the
> domain part. Apart from that this regexp will reject email addresses
> which are valid according to RFC 3696 like foo+bar@example.com
>
> Uli
>
> andyhot schrieb:
>> hmmm - nice report - looks like that specific email regex is
>> problematic when
>> the given string is not email and contains lots of chars (>25-30
>> result in more than 100000 iterations
>> according to RegexBuddy) - we'll probably have to find a better regex
>> i guess
>>
>> http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html looks quite
>> interesting though ;)
>>
>> Christian Dutaret wrote:
>>> Hi all,
>>>
>>> Occasionally, my T4.1.3 application running on tomcat/jdk5/linux gets to
>>> take 100% CPU and then never release it until I restart the JVM. Doesn't
>>> happen too often, maybe 5 times in a few months. After I restart Tomcat,
>>> everything goes back to normal.
>>> I eventually decided to try to find out the suspected infinite loop that
>>> causes all this. So I did a thread dump on the JVM, identified the
>>> cpu-consuming threads. I found 3 threads wasting 33% of the CPU each,
>>> and
>>> according to the thread dump, they're all running infinite loops on
>>> regexp
>>> matching. Here is an extract of the thread dump for one of these
>>> threads :
>>>
>>> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
>>> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
>>> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
>>> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
>>> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
>>> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
>>> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
>>> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
>>> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
>>> at java.util.regex.Pattern$Loop.matchInit(Pattern.java:4721)
>>> at java.util.regex.Pattern$Prolog.match(Pattern.java:4658)
>>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>>> at java.util.regex.Pattern$Begin.match(Pattern.java:3084)
>>> at java.util.regex.Matcher.match(Matcher.java:1114)
>>> at java.util.regex.Matcher.matches(Matcher.java:495)
>>> at
>>> org.apache.tapestry.util.RegexpMatcher.matches(RegexpMatcher.java
>>> :71)
>>> at
>>> org.apache.tapestry.form.validator.Email.validate(Email.java:61)
>>> at
>>> org.apache.tapestry.form.ValidatableFieldSupportImpl.validate(
>>> ValidatableFieldSupportImpl.java:99)
>>> at
>>> $ValidatableFieldSupport_115c315e3ad.validate($ValidatableFieldSupport_115c315e3ad.java)
>>>
>>> at org.apache.tapestry.form.TextField.rewindFormComponent(
>>> TextField.java:103)
>>>
>>> As you can see, it seems that the email validator regexp matching
>>> causes an
>>> infinite loop in some rare cases. Unfortunately, I am not able to
>>> retrieve
>>> which values did cause this.
>>>
>>> In the mean time, I'll try my own simpler regexp, or maybe I'll just
>>> skip
>>> email validation until I get a better idea.
>>>
>>> Thanks for any hint on this
>>>
>>> Ch.
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T4.1.3 : 100% CPU usage on tomcat due to server-side email validation
Posted by Ulrich Stärk <ul...@spielviel.de>.
I just came to the same conclusion. The problem is with the
([-_\\.]*[A-Za-z0-9]+)* part of the regexp in the user as well as the
domain part. Apart from that this regexp will reject email addresses
which are valid according to RFC 3696 like foo+bar@example.com
Uli
andyhot schrieb:
> hmmm - nice report - looks like that specific email regex is problematic
> when
> the given string is not email and contains lots of chars (>25-30 result
> in more than 100000 iterations
> according to RegexBuddy) - we'll probably have to find a better regex i
> guess
>
> http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html looks quite
> interesting though ;)
>
> Christian Dutaret wrote:
>> Hi all,
>>
>> Occasionally, my T4.1.3 application running on tomcat/jdk5/linux gets to
>> take 100% CPU and then never release it until I restart the JVM. Doesn't
>> happen too often, maybe 5 times in a few months. After I restart Tomcat,
>> everything goes back to normal.
>> I eventually decided to try to find out the suspected infinite loop that
>> causes all this. So I did a thread dump on the JVM, identified the
>> cpu-consuming threads. I found 3 threads wasting 33% of the CPU each, and
>> according to the thread dump, they're all running infinite loops on
>> regexp
>> matching. Here is an extract of the thread dump for one of these
>> threads :
>>
>> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
>> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
>> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
>> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
>> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
>> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
>> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
>> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
>> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
>> at java.util.regex.Pattern$Loop.matchInit(Pattern.java:4721)
>> at java.util.regex.Pattern$Prolog.match(Pattern.java:4658)
>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>> at java.util.regex.Pattern$Begin.match(Pattern.java:3084)
>> at java.util.regex.Matcher.match(Matcher.java:1114)
>> at java.util.regex.Matcher.matches(Matcher.java:495)
>> at
>> org.apache.tapestry.util.RegexpMatcher.matches(RegexpMatcher.java
>> :71)
>> at
>> org.apache.tapestry.form.validator.Email.validate(Email.java:61)
>> at org.apache.tapestry.form.ValidatableFieldSupportImpl.validate(
>> ValidatableFieldSupportImpl.java:99)
>> at
>> $ValidatableFieldSupport_115c315e3ad.validate($ValidatableFieldSupport_115c315e3ad.java)
>>
>> at org.apache.tapestry.form.TextField.rewindFormComponent(
>> TextField.java:103)
>>
>> As you can see, it seems that the email validator regexp matching
>> causes an
>> infinite loop in some rare cases. Unfortunately, I am not able to
>> retrieve
>> which values did cause this.
>>
>> In the mean time, I'll try my own simpler regexp, or maybe I'll just skip
>> email validation until I get a better idea.
>>
>> Thanks for any hint on this
>>
>> Ch.
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T4.1.3 : 100% CPU usage on tomcat due to server-side email validation
Posted by Ulrich Stärk <ul...@spielviel.de>.
I now remember where I saw that one before. Jeffrey Friedl included it
in "Mastering Regular Expressions". In print! :)
Uli
andyhot schrieb:
> hmmm - nice report - looks like that specific email regex is problematic
> when
> the given string is not email and contains lots of chars (>25-30 result
> in more than 100000 iterations
> according to RegexBuddy) - we'll probably have to find a better regex i
> guess
>
> http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html looks quite
> interesting though ;)
>
> Christian Dutaret wrote:
>> Hi all,
>>
>> Occasionally, my T4.1.3 application running on tomcat/jdk5/linux gets to
>> take 100% CPU and then never release it until I restart the JVM. Doesn't
>> happen too often, maybe 5 times in a few months. After I restart Tomcat,
>> everything goes back to normal.
>> I eventually decided to try to find out the suspected infinite loop that
>> causes all this. So I did a thread dump on the JVM, identified the
>> cpu-consuming threads. I found 3 threads wasting 33% of the CPU each, and
>> according to the thread dump, they're all running infinite loops on
>> regexp
>> matching. Here is an extract of the thread dump for one of these
>> threads :
>>
>> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
>> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
>> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
>> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
>> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
>> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
>> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
>> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
>> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
>> at java.util.regex.Pattern$Loop.matchInit(Pattern.java:4721)
>> at java.util.regex.Pattern$Prolog.match(Pattern.java:4658)
>> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
>> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
>> at java.util.regex.Pattern$Begin.match(Pattern.java:3084)
>> at java.util.regex.Matcher.match(Matcher.java:1114)
>> at java.util.regex.Matcher.matches(Matcher.java:495)
>> at
>> org.apache.tapestry.util.RegexpMatcher.matches(RegexpMatcher.java
>> :71)
>> at
>> org.apache.tapestry.form.validator.Email.validate(Email.java:61)
>> at org.apache.tapestry.form.ValidatableFieldSupportImpl.validate(
>> ValidatableFieldSupportImpl.java:99)
>> at
>> $ValidatableFieldSupport_115c315e3ad.validate($ValidatableFieldSupport_115c315e3ad.java)
>>
>> at org.apache.tapestry.form.TextField.rewindFormComponent(
>> TextField.java:103)
>>
>> As you can see, it seems that the email validator regexp matching
>> causes an
>> infinite loop in some rare cases. Unfortunately, I am not able to
>> retrieve
>> which values did cause this.
>>
>> In the mean time, I'll try my own simpler regexp, or maybe I'll just skip
>> email validation until I get a better idea.
>>
>> Thanks for any hint on this
>>
>> Ch.
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T4.1.3 : 100% CPU usage on tomcat due to server-side email validation
Posted by andyhot <an...@di.uoa.gr>.
hmmm - nice report - looks like that specific email regex is problematic
when
the given string is not email and contains lots of chars (>25-30 result
in more than 100000 iterations
according to RegexBuddy) - we'll probably have to find a better regex i
guess
http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html looks quite
interesting though ;)
Christian Dutaret wrote:
> Hi all,
>
> Occasionally, my T4.1.3 application running on tomcat/jdk5/linux gets to
> take 100% CPU and then never release it until I restart the JVM. Doesn't
> happen too often, maybe 5 times in a few months. After I restart Tomcat,
> everything goes back to normal.
> I eventually decided to try to find out the suspected infinite loop that
> causes all this. So I did a thread dump on the JVM, identified the
> cpu-consuming threads. I found 3 threads wasting 33% of the CPU each, and
> according to the thread dump, they're all running infinite loops on regexp
> matching. Here is an extract of the thread dump for one of these threads :
>
> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
> at java.util.regex.Pattern$Loop.match(Pattern.java:4702)
> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4634)
> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
> at java.util.regex.Pattern$Curly.match0(Pattern.java:4247)
> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4575)
> at java.util.regex.Pattern$Loop.matchInit(Pattern.java:4721)
> at java.util.regex.Pattern$Prolog.match(Pattern.java:4658)
> at java.util.regex.Pattern$Curly.match0(Pattern.java:4240)
> at java.util.regex.Pattern$Curly.match(Pattern.java:4202)
> at java.util.regex.Pattern$Begin.match(Pattern.java:3084)
> at java.util.regex.Matcher.match(Matcher.java:1114)
> at java.util.regex.Matcher.matches(Matcher.java:495)
> at org.apache.tapestry.util.RegexpMatcher.matches(RegexpMatcher.java
> :71)
> at org.apache.tapestry.form.validator.Email.validate(Email.java:61)
> at org.apache.tapestry.form.ValidatableFieldSupportImpl.validate(
> ValidatableFieldSupportImpl.java:99)
> at
> $ValidatableFieldSupport_115c315e3ad.validate($ValidatableFieldSupport_115c315e3ad.java)
> at org.apache.tapestry.form.TextField.rewindFormComponent(
> TextField.java:103)
>
> As you can see, it seems that the email validator regexp matching causes an
> infinite loop in some rare cases. Unfortunately, I am not able to retrieve
> which values did cause this.
>
> In the mean time, I'll try my own simpler regexp, or maybe I'll just skip
> email validation until I get a better idea.
>
> Thanks for any hint on this
>
> Ch.
>
>
--
Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
Tapestry / Tacos developer
Open Source / JEE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org