You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Mohammed Manna <ma...@gmail.com> on 2017/04/26 08:06:38 UTC
Fwd: Identifying 64k size violation for __jspService methods loaded
by Tomcat
---------- Forwarded message ----------
From: Mohammed Manna <ma...@gmail.com>
Date: 25 April 2017 at 21:50
Subject: Identifying 64k size violation for __jspService methods loaded by
Tomcat
To: users@tomcat.apache.org
Hello,
I have emailed and posted a few questions over the web about this, but
haven't received any helpful response. Since the upgrade to 8.0.39, my web
application is failing in various places since the Jasper compiler has now
got more debug information (and inturn __jspService method is now bigger
than 64k). I have done the following so far:
1) Kept mappedFile = TRUE
2) Kept suppressSMAP = FALSE
This removes the failure, but now I have lost the JSP debugging capability.
Since Apache is not going to provide any support for this, could you kindly
assist me with the following:
1) How can I identify my JSP pages which are going to have this issue?
2) I have tried using ANT build and compiled my JSPs. It simply passes the
build, but doesn't report any method size violation. Do you have any
development mode support that can expose these affected methods.
I appreciate that these are too specific questions, but Tomcat 8.0.39
upgrade clearly didn't consider legacy systems and has left a massive
refactoring job to the developers. So, it would be great if you could
proactively extend "Known Issues" section with these.
KR,
Re: Identifying 64k size violation for __jspService methods loaded by Tomcat
Posted by Violeta Georgieva <vi...@apache.org>.
Hi,
2017-04-26 11:06 GMT+03:00 Mohammed Manna <ma...@gmail.com>:
>
> ---------- Forwarded message ----------
> From: Mohammed Manna <ma...@gmail.com>
> Date: 25 April 2017 at 21:50
> Subject: Identifying 64k size violation for __jspService methods loaded by
> Tomcat
> To: users@tomcat.apache.org
>
>
> Hello,
>
> I have emailed and posted a few questions over the web about this, but
> haven't received any helpful response. Since the upgrade to 8.0.39, my web
> application is failing in various places since the Jasper compiler has now
> got more debug information (and inturn __jspService method is now bigger
> than 64k). I have done the following so far:
We have changes related to that issue.[1]
So update your Tomcat instance to the latest Tomcat 8.0 (8.0.43)
Regards,
Violeta
[1] http://tomcat.apache.org/tomcat-8.0-doc/changelog.html
>
> 1) Kept mappedFile = TRUE
> 2) Kept suppressSMAP = FALSE
>
> This removes the failure, but now I have lost the JSP debugging
capability.
> Since Apache is not going to provide any support for this, could you
kindly
> assist me with the following:
>
> 1) How can I identify my JSP pages which are going to have this issue?
> 2) I have tried using ANT build and compiled my JSPs. It simply passes the
> build, but doesn't report any method size violation. Do you have any
> development mode support that can expose these affected methods.
>
> I appreciate that these are too specific questions, but Tomcat 8.0.39
> upgrade clearly didn't consider legacy systems and has left a massive
> refactoring job to the developers. So, it would be great if you could
> proactively extend "Known Issues" section with these.
>
> KR,
Re: Fwd: Identifying 64k size violation for __jspService methods
loaded by Tomcat
Posted by Mark Thomas <ma...@apache.org>.
On 01/05/17 20:24, Mohammed Manna wrote:
> Hi,
>
> May be i didn't explain the issue clearly. I am using the same compiler as
> Tomcat (JDT compiler, not ANT).
Ant isn't a complier. It is a build tool. Ant uses javac (i.e.
tools.jar) to build with.
> When doing a standalone *ant build*, my
> pre-compilation doesn't show any 64k size error for __jspService(). But
> when I launch the application, it *does* throws error on 64k size on
> various pages.
>
> Just for the sake of comparison, I did the following:
>
> 1) Threw a purposefully generated error on ant build - captured to stack to
> see which compiler implementation it followings - JDT compiler
Show us the stack trace please.
> 2) Corrected the error above and passed the build
> 3) Deployed and launched the application.
Did you deploy the pre-compiled application?
> 4) Went to the problem page - generated the 64k error to capture the stack
> information.
> 5) The compiler implementation is the same as reported on Ant Build error
> (JDTCompiler).
If javac can compile the page without error then you should either:
a) use those pre-compiled pages
b) configure Tomcat to do on-the0fly compilation with javac.
> This is why I have been struggling to understand why the behaviour is so
> different when the compiler isn't ?
I'm not convinced you are using the compiler you think you are.
> Is there any tuning of <*javac> *task definition in ant build I can use?
> What do you recommend?
Answer the above questions.
Provide a simple as possible JSP (probably one that uses a single tag
repeatedly) that demonstrates the problem.
Mark
>
> KR,
>
> from the JspCompilationContext, what I can see is that it will use JDT
> compiler when nothing is specified and the compilation will be based on 1.7
> standard. Which means my *ant build* will also use JDT compiler
> (org.apache.jasper.compiler.JDTCompiler). This is why I have been
> struggling to understand why this is so different if
> On 30 Apr 2017 12:05, "Mark Thomas" <ma...@apache.org> wrote:
>
> On 29/04/17 11:10, Mohammed Manna wrote:
>> Hello,
>>
>> I have retried using the following javac and jasper settings for my
> project
>> (using ANT build) - and it still doesn't reveal those 64K errors even when
>> the compilers are the same.
>
> Isn't that good? Doesn't that mean you've found a solution to the
> problem? Compile with Ant and javac rather than JDT.
>
> Mark
>
>>
>> <!-- Configure Jasper -->
>> <target name="jspc" depends="build.web">
>> <taskdef classname="org.apache.jasper.JspC" name="jasper2">
>> <classpath id="jspc.classpath">
>> <pathelement location="${java.home}/../lib/tools.jar"/>
>> <fileset dir="bin">
>> <include name="*.jar"/>
>> </fileset>
>> <fileset dir="lib">
>> <include name="*.jar"/>
>> </fileset>
>> </classpath>
>> </taskdef>
>>
>> <jasper2
>> validateXml="false"
>> uriroot="webapps/${webdir}"
>> webXmlFragment="work/generated_web.xml"
>> outputDir="work/jsp"
>> smapsuppressed="0"
>> compilersourcevm="1.8"
>> compilertargetvm="1.8"
>> mappedfile="1"/>
>> </target>
>>
>> <!-- Compile JSP -->
>> <target name="compile.jsp" depends="jspc" >
>> <javac compiler="javac1.8"
>> destdir="work/jsp"
>> optimize="off"
>> debug="on"
>> failOnError="false"
>> srcdir="work/jsp">
>>
>> <classpath>
>> <pathelement location="webapps/${webdir}/WE
> B-INF/classes"/>
>> <fileset dir="webapps/${webdir}/WEB-INF/lib">
>> <include name="*.jar"/>
>> </fileset>
>> <fileset dir="lib">
>> <include name="*.jar"/>
>> </fileset>
>> <fileset dir="bin">
>> <include name="*.jar"/>
>> </fileset>
>> </classpath>
>> <include name="**"/>
>> <exclude name="tags/**"/>
>> </javac>
>> </target>
>>
>> I set my environment variables for catalina and java as part of my tomcat
>> start script. And both ANT and Tomcat are using the same compiler as i
>> understand from ant task documentation. Is there anything else I can do to
>> reveal the 64k size errors on the method?
>>
>> KR,
>>
>> On 26 April 2017 at 11:24, Mark Thomas <ma...@apache.org> wrote:
>>
>>> On 26/04/17 10:33, Mohammed Manna wrote:
>>>> Hello,
>>>>
>>>> Thanks for suggesting the solutions. This is closer to what I was
>>> expecting
>>>> in the original message which I sent in the past. Once again, I
>>> apologise
>>>> if I have made any Negative/Reactive comments about Apache no being
>>>> supportive enough. I have been using various Apache libraries over the
>>> past
>>>> 7 years without any issues. But this particular Tomcat upgrade has
> caused
>>>> me significant grief in managing large projects where 9/10 systems are
>>>> legacy code base. I do agree that the JSPs need to be refactored to
>>> remove
>>>> any obsolescence. But until your response, I have only received
> responses
>>>> where I was asked to upgrade to a different version, but I am more
>>> curious
>>>> to find out the root cause for this.
>>>>
>>>> Unfortunately, I have to leave with *enablePooling=TRUE, *since it might
>>>> affect things. I will however try to reconfigure Jasper and use my
> native
>>>> Java 1.8.121 to do all the compilation and see how things go.
>>>>
>>>> Unless I have misunderstood, Tomcat 8.0.43 will not stop this error but
>>>> minimise the occurrences of it. Is this correct?
>>>
>>> Correct. The error handling code was refactored for 8.0.42 onwards to be
>>> a little more efficient. It isn't much but if your code is on the border
>>> line it might be enough to bring it back under the 64k.
>>>
>>> Mark
>>>
>>>
>>>>
>>>>
>>>> Additionally, thanks to you for putting a lot more attention to it.
>>>>
>>>> KR,
>>>>
>>>>
>>>>
>>>>
>>>> On 26 April 2017 at 09:58, Mark Thomas <ma...@apache.org> wrote:
>>>>
>>>>> On 26/04/17 09:06, Mohammed Manna wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I have emailed and posted a few questions over the web about this, but
>>>>>> haven't received any helpful response. Since the upgrade to 8.0.39, my
>>>>> web
>>>>>> application is failing in various places since the Jasper compiler has
>>>>> now
>>>>>> got more debug information (and inturn __jspService method is now
>>> bigger
>>>>>> than 64k).
>>>>>
>>>>> First a correction. The changes were not made to introduce additional
>>>>> debug information. The changes introduced additional - specification
>>>>> required - error handling for tags. The changes were the result of
>>>>> investigating a reported memory leak [1].
>>>>>
>>>>>> I have done the following so far:
>>>>>>
>>>>>> 1) Kept mappedFile = TRUE
>>>>>> 2) Kept suppressSMAP = FALSE
>>>>>>
>>>>>> This removes the failure, but now I have lost the JSP debugging
>>>>> capability.
>>>>>> Since Apache is not going to provide any support for this, could you
>>>>> kindly
>>>>>> assist me with the following:
>>>>>
>>>>> First you say Apache isn't going to provide you with any support
>>>>> (despite this being your first post on this topic) then you ask this
>>>>> Apache community for that same support. That isn't the best way to
>>>>> motivate a group of volunteers to help you.
>>>>>
>>>>> The initial fix was in 8.0.37.
>>>>> A regression was fixed in 8.0.40.
>>>>> A more efficient solution was provided in 8.0.42.
>>>>> An improved solution for simple tags was in 8.0.43
>>>>>
>>>>> The first recommendation is to upgrade to 8.0.43. The more efficient
>>>>> code introduced in 8.0.42 may help.
>>>>>
>>>>> Other configuration settings that can help reduce the size of your JSP
>>>>> methods include:
>>>>>
>>>>> trimSpaces - true
>>>>> enablePooling - false
>>>>>
>>>>> Note the disabling pooling may impact performance. It depends on lot on
>>>>> the complexity of the tags.
>>>>>
>>>>>> 1) How can I identify my JSP pages which are going to have this issue?
>>>>>> 2) I have tried using ANT build and compiled my JSPs. It simply passes
>>>>> the
>>>>>> build, but doesn't report any method size violation. Do you have any
>>>>>> development mode support that can expose these affected methods.
>>>>>
>>>>> Do those pre-compiled JSPs then execute without error?
>>>>>
>>>>> Pre-compilation typically uses javac whereas on the fly compilation
>>>>> typically uses JDT (the Eclipse Compiler). It is possible that
>>>>> differences in the compilers means that a class compiles with one but
>>>>> fails with the other - particularly if your code is close to the
>>> boundary.
>>>>>
>>>>> It is possible to configure Jasper to compile JSPs with Ant and javac
>>>>> (see the compiler init parameter).
>>>>>
>>>>> I suggest you try the recommendations above and see how you get on.
>>>>>
>>>>>> I appreciate that these are too specific questions, but Tomcat 8.0.39
>>>>>> upgrade clearly didn't consider legacy systems and has left a massive
>>>>>> refactoring job to the developers. So, it would be great if you could
>>>>>> proactively extend "Known Issues" section with these.
>>>>>
>>>>> Patches welcome.
>>>>>
>>>>> Mark
>>>>>
>>>>>
>>>>> [1] http://tomcat.markmail.org/thread/6jz7wfpcse6oxdgd
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Fwd: Identifying 64k size violation for __jspService methods
loaded by Tomcat
Posted by Mohammed Manna <ma...@gmail.com>.
Hi,
May be i didn't explain the issue clearly. I am using the same compiler as
Tomcat (JDT compiler, not ANT). When doing a standalone *ant build*, my
pre-compilation doesn't show any 64k size error for __jspService(). But
when I launch the application, it *does* throws error on 64k size on
various pages.
Just for the sake of comparison, I did the following:
1) Threw a purposefully generated error on ant build - captured to stack to
see which compiler implementation it followings - JDT compiler
2) Corrected the error above and passed the build
3) Deployed and launched the application.
4) Went to the problem page - generated the 64k error to capture the stack
information.
5) The compiler implementation is the same as reported on Ant Build error
(JDTCompiler).
This is why I have been struggling to understand why the behaviour is so
different when the compiler isn't ?
Is there any tuning of <*javac> *task definition in ant build I can use?
What do you recommend?
KR,
from the JspCompilationContext, what I can see is that it will use JDT
compiler when nothing is specified and the compilation will be based on 1.7
standard. Which means my *ant build* will also use JDT compiler
(org.apache.jasper.compiler.JDTCompiler). This is why I have been
struggling to understand why this is so different if
On 30 Apr 2017 12:05, "Mark Thomas" <ma...@apache.org> wrote:
On 29/04/17 11:10, Mohammed Manna wrote:
> Hello,
>
> I have retried using the following javac and jasper settings for my
project
> (using ANT build) - and it still doesn't reveal those 64K errors even when
> the compilers are the same.
Isn't that good? Doesn't that mean you've found a solution to the
problem? Compile with Ant and javac rather than JDT.
Mark
>
> <!-- Configure Jasper -->
> <target name="jspc" depends="build.web">
> <taskdef classname="org.apache.jasper.JspC" name="jasper2">
> <classpath id="jspc.classpath">
> <pathelement location="${java.home}/../lib/tools.jar"/>
> <fileset dir="bin">
> <include name="*.jar"/>
> </fileset>
> <fileset dir="lib">
> <include name="*.jar"/>
> </fileset>
> </classpath>
> </taskdef>
>
> <jasper2
> validateXml="false"
> uriroot="webapps/${webdir}"
> webXmlFragment="work/generated_web.xml"
> outputDir="work/jsp"
> smapsuppressed="0"
> compilersourcevm="1.8"
> compilertargetvm="1.8"
> mappedfile="1"/>
> </target>
>
> <!-- Compile JSP -->
> <target name="compile.jsp" depends="jspc" >
> <javac compiler="javac1.8"
> destdir="work/jsp"
> optimize="off"
> debug="on"
> failOnError="false"
> srcdir="work/jsp">
>
> <classpath>
> <pathelement location="webapps/${webdir}/WE
B-INF/classes"/>
> <fileset dir="webapps/${webdir}/WEB-INF/lib">
> <include name="*.jar"/>
> </fileset>
> <fileset dir="lib">
> <include name="*.jar"/>
> </fileset>
> <fileset dir="bin">
> <include name="*.jar"/>
> </fileset>
> </classpath>
> <include name="**"/>
> <exclude name="tags/**"/>
> </javac>
> </target>
>
> I set my environment variables for catalina and java as part of my tomcat
> start script. And both ANT and Tomcat are using the same compiler as i
> understand from ant task documentation. Is there anything else I can do to
> reveal the 64k size errors on the method?
>
> KR,
>
> On 26 April 2017 at 11:24, Mark Thomas <ma...@apache.org> wrote:
>
>> On 26/04/17 10:33, Mohammed Manna wrote:
>>> Hello,
>>>
>>> Thanks for suggesting the solutions. This is closer to what I was
>> expecting
>>> in the original message which I sent in the past. Once again, I
>> apologise
>>> if I have made any Negative/Reactive comments about Apache no being
>>> supportive enough. I have been using various Apache libraries over the
>> past
>>> 7 years without any issues. But this particular Tomcat upgrade has
caused
>>> me significant grief in managing large projects where 9/10 systems are
>>> legacy code base. I do agree that the JSPs need to be refactored to
>> remove
>>> any obsolescence. But until your response, I have only received
responses
>>> where I was asked to upgrade to a different version, but I am more
>> curious
>>> to find out the root cause for this.
>>>
>>> Unfortunately, I have to leave with *enablePooling=TRUE, *since it might
>>> affect things. I will however try to reconfigure Jasper and use my
native
>>> Java 1.8.121 to do all the compilation and see how things go.
>>>
>>> Unless I have misunderstood, Tomcat 8.0.43 will not stop this error but
>>> minimise the occurrences of it. Is this correct?
>>
>> Correct. The error handling code was refactored for 8.0.42 onwards to be
>> a little more efficient. It isn't much but if your code is on the border
>> line it might be enough to bring it back under the 64k.
>>
>> Mark
>>
>>
>>>
>>>
>>> Additionally, thanks to you for putting a lot more attention to it.
>>>
>>> KR,
>>>
>>>
>>>
>>>
>>> On 26 April 2017 at 09:58, Mark Thomas <ma...@apache.org> wrote:
>>>
>>>> On 26/04/17 09:06, Mohammed Manna wrote:
>>>>> Hello,
>>>>>
>>>>> I have emailed and posted a few questions over the web about this, but
>>>>> haven't received any helpful response. Since the upgrade to 8.0.39, my
>>>> web
>>>>> application is failing in various places since the Jasper compiler has
>>>> now
>>>>> got more debug information (and inturn __jspService method is now
>> bigger
>>>>> than 64k).
>>>>
>>>> First a correction. The changes were not made to introduce additional
>>>> debug information. The changes introduced additional - specification
>>>> required - error handling for tags. The changes were the result of
>>>> investigating a reported memory leak [1].
>>>>
>>>>> I have done the following so far:
>>>>>
>>>>> 1) Kept mappedFile = TRUE
>>>>> 2) Kept suppressSMAP = FALSE
>>>>>
>>>>> This removes the failure, but now I have lost the JSP debugging
>>>> capability.
>>>>> Since Apache is not going to provide any support for this, could you
>>>> kindly
>>>>> assist me with the following:
>>>>
>>>> First you say Apache isn't going to provide you with any support
>>>> (despite this being your first post on this topic) then you ask this
>>>> Apache community for that same support. That isn't the best way to
>>>> motivate a group of volunteers to help you.
>>>>
>>>> The initial fix was in 8.0.37.
>>>> A regression was fixed in 8.0.40.
>>>> A more efficient solution was provided in 8.0.42.
>>>> An improved solution for simple tags was in 8.0.43
>>>>
>>>> The first recommendation is to upgrade to 8.0.43. The more efficient
>>>> code introduced in 8.0.42 may help.
>>>>
>>>> Other configuration settings that can help reduce the size of your JSP
>>>> methods include:
>>>>
>>>> trimSpaces - true
>>>> enablePooling - false
>>>>
>>>> Note the disabling pooling may impact performance. It depends on lot on
>>>> the complexity of the tags.
>>>>
>>>>> 1) How can I identify my JSP pages which are going to have this issue?
>>>>> 2) I have tried using ANT build and compiled my JSPs. It simply passes
>>>> the
>>>>> build, but doesn't report any method size violation. Do you have any
>>>>> development mode support that can expose these affected methods.
>>>>
>>>> Do those pre-compiled JSPs then execute without error?
>>>>
>>>> Pre-compilation typically uses javac whereas on the fly compilation
>>>> typically uses JDT (the Eclipse Compiler). It is possible that
>>>> differences in the compilers means that a class compiles with one but
>>>> fails with the other - particularly if your code is close to the
>> boundary.
>>>>
>>>> It is possible to configure Jasper to compile JSPs with Ant and javac
>>>> (see the compiler init parameter).
>>>>
>>>> I suggest you try the recommendations above and see how you get on.
>>>>
>>>>> I appreciate that these are too specific questions, but Tomcat 8.0.39
>>>>> upgrade clearly didn't consider legacy systems and has left a massive
>>>>> refactoring job to the developers. So, it would be great if you could
>>>>> proactively extend "Known Issues" section with these.
>>>>
>>>> Patches welcome.
>>>>
>>>> Mark
>>>>
>>>>
>>>> [1] http://tomcat.markmail.org/thread/6jz7wfpcse6oxdgd
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Fwd: Identifying 64k size violation for __jspService methods
loaded by Tomcat
Posted by Mark Thomas <ma...@apache.org>.
On 29/04/17 11:10, Mohammed Manna wrote:
> Hello,
>
> I have retried using the following javac and jasper settings for my project
> (using ANT build) - and it still doesn't reveal those 64K errors even when
> the compilers are the same.
Isn't that good? Doesn't that mean you've found a solution to the
problem? Compile with Ant and javac rather than JDT.
Mark
>
> <!-- Configure Jasper -->
> <target name="jspc" depends="build.web">
> <taskdef classname="org.apache.jasper.JspC" name="jasper2">
> <classpath id="jspc.classpath">
> <pathelement location="${java.home}/../lib/tools.jar"/>
> <fileset dir="bin">
> <include name="*.jar"/>
> </fileset>
> <fileset dir="lib">
> <include name="*.jar"/>
> </fileset>
> </classpath>
> </taskdef>
>
> <jasper2
> validateXml="false"
> uriroot="webapps/${webdir}"
> webXmlFragment="work/generated_web.xml"
> outputDir="work/jsp"
> smapsuppressed="0"
> compilersourcevm="1.8"
> compilertargetvm="1.8"
> mappedfile="1"/>
> </target>
>
> <!-- Compile JSP -->
> <target name="compile.jsp" depends="jspc" >
> <javac compiler="javac1.8"
> destdir="work/jsp"
> optimize="off"
> debug="on"
> failOnError="false"
> srcdir="work/jsp">
>
> <classpath>
> <pathelement location="webapps/${webdir}/WEB-INF/classes"/>
> <fileset dir="webapps/${webdir}/WEB-INF/lib">
> <include name="*.jar"/>
> </fileset>
> <fileset dir="lib">
> <include name="*.jar"/>
> </fileset>
> <fileset dir="bin">
> <include name="*.jar"/>
> </fileset>
> </classpath>
> <include name="**"/>
> <exclude name="tags/**"/>
> </javac>
> </target>
>
> I set my environment variables for catalina and java as part of my tomcat
> start script. And both ANT and Tomcat are using the same compiler as i
> understand from ant task documentation. Is there anything else I can do to
> reveal the 64k size errors on the method?
>
> KR,
>
> On 26 April 2017 at 11:24, Mark Thomas <ma...@apache.org> wrote:
>
>> On 26/04/17 10:33, Mohammed Manna wrote:
>>> Hello,
>>>
>>> Thanks for suggesting the solutions. This is closer to what I was
>> expecting
>>> in the original message which I sent in the past. Once again, I
>> apologise
>>> if I have made any Negative/Reactive comments about Apache no being
>>> supportive enough. I have been using various Apache libraries over the
>> past
>>> 7 years without any issues. But this particular Tomcat upgrade has caused
>>> me significant grief in managing large projects where 9/10 systems are
>>> legacy code base. I do agree that the JSPs need to be refactored to
>> remove
>>> any obsolescence. But until your response, I have only received responses
>>> where I was asked to upgrade to a different version, but I am more
>> curious
>>> to find out the root cause for this.
>>>
>>> Unfortunately, I have to leave with *enablePooling=TRUE, *since it might
>>> affect things. I will however try to reconfigure Jasper and use my native
>>> Java 1.8.121 to do all the compilation and see how things go.
>>>
>>> Unless I have misunderstood, Tomcat 8.0.43 will not stop this error but
>>> minimise the occurrences of it. Is this correct?
>>
>> Correct. The error handling code was refactored for 8.0.42 onwards to be
>> a little more efficient. It isn't much but if your code is on the border
>> line it might be enough to bring it back under the 64k.
>>
>> Mark
>>
>>
>>>
>>>
>>> Additionally, thanks to you for putting a lot more attention to it.
>>>
>>> KR,
>>>
>>>
>>>
>>>
>>> On 26 April 2017 at 09:58, Mark Thomas <ma...@apache.org> wrote:
>>>
>>>> On 26/04/17 09:06, Mohammed Manna wrote:
>>>>> Hello,
>>>>>
>>>>> I have emailed and posted a few questions over the web about this, but
>>>>> haven't received any helpful response. Since the upgrade to 8.0.39, my
>>>> web
>>>>> application is failing in various places since the Jasper compiler has
>>>> now
>>>>> got more debug information (and inturn __jspService method is now
>> bigger
>>>>> than 64k).
>>>>
>>>> First a correction. The changes were not made to introduce additional
>>>> debug information. The changes introduced additional - specification
>>>> required - error handling for tags. The changes were the result of
>>>> investigating a reported memory leak [1].
>>>>
>>>>> I have done the following so far:
>>>>>
>>>>> 1) Kept mappedFile = TRUE
>>>>> 2) Kept suppressSMAP = FALSE
>>>>>
>>>>> This removes the failure, but now I have lost the JSP debugging
>>>> capability.
>>>>> Since Apache is not going to provide any support for this, could you
>>>> kindly
>>>>> assist me with the following:
>>>>
>>>> First you say Apache isn't going to provide you with any support
>>>> (despite this being your first post on this topic) then you ask this
>>>> Apache community for that same support. That isn't the best way to
>>>> motivate a group of volunteers to help you.
>>>>
>>>> The initial fix was in 8.0.37.
>>>> A regression was fixed in 8.0.40.
>>>> A more efficient solution was provided in 8.0.42.
>>>> An improved solution for simple tags was in 8.0.43
>>>>
>>>> The first recommendation is to upgrade to 8.0.43. The more efficient
>>>> code introduced in 8.0.42 may help.
>>>>
>>>> Other configuration settings that can help reduce the size of your JSP
>>>> methods include:
>>>>
>>>> trimSpaces - true
>>>> enablePooling - false
>>>>
>>>> Note the disabling pooling may impact performance. It depends on lot on
>>>> the complexity of the tags.
>>>>
>>>>> 1) How can I identify my JSP pages which are going to have this issue?
>>>>> 2) I have tried using ANT build and compiled my JSPs. It simply passes
>>>> the
>>>>> build, but doesn't report any method size violation. Do you have any
>>>>> development mode support that can expose these affected methods.
>>>>
>>>> Do those pre-compiled JSPs then execute without error?
>>>>
>>>> Pre-compilation typically uses javac whereas on the fly compilation
>>>> typically uses JDT (the Eclipse Compiler). It is possible that
>>>> differences in the compilers means that a class compiles with one but
>>>> fails with the other - particularly if your code is close to the
>> boundary.
>>>>
>>>> It is possible to configure Jasper to compile JSPs with Ant and javac
>>>> (see the compiler init parameter).
>>>>
>>>> I suggest you try the recommendations above and see how you get on.
>>>>
>>>>> I appreciate that these are too specific questions, but Tomcat 8.0.39
>>>>> upgrade clearly didn't consider legacy systems and has left a massive
>>>>> refactoring job to the developers. So, it would be great if you could
>>>>> proactively extend "Known Issues" section with these.
>>>>
>>>> Patches welcome.
>>>>
>>>> Mark
>>>>
>>>>
>>>> [1] http://tomcat.markmail.org/thread/6jz7wfpcse6oxdgd
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Fwd: Identifying 64k size violation for __jspService methods
loaded by Tomcat
Posted by Mohammed Manna <ma...@gmail.com>.
Hello,
I have retried using the following javac and jasper settings for my project
(using ANT build) - and it still doesn't reveal those 64K errors even when
the compilers are the same.
<!-- Configure Jasper -->
<target name="jspc" depends="build.web">
<taskdef classname="org.apache.jasper.JspC" name="jasper2">
<classpath id="jspc.classpath">
<pathelement location="${java.home}/../lib/tools.jar"/>
<fileset dir="bin">
<include name="*.jar"/>
</fileset>
<fileset dir="lib">
<include name="*.jar"/>
</fileset>
</classpath>
</taskdef>
<jasper2
validateXml="false"
uriroot="webapps/${webdir}"
webXmlFragment="work/generated_web.xml"
outputDir="work/jsp"
smapsuppressed="0"
compilersourcevm="1.8"
compilertargetvm="1.8"
mappedfile="1"/>
</target>
<!-- Compile JSP -->
<target name="compile.jsp" depends="jspc" >
<javac compiler="javac1.8"
destdir="work/jsp"
optimize="off"
debug="on"
failOnError="false"
srcdir="work/jsp">
<classpath>
<pathelement location="webapps/${webdir}/WEB-INF/classes"/>
<fileset dir="webapps/${webdir}/WEB-INF/lib">
<include name="*.jar"/>
</fileset>
<fileset dir="lib">
<include name="*.jar"/>
</fileset>
<fileset dir="bin">
<include name="*.jar"/>
</fileset>
</classpath>
<include name="**"/>
<exclude name="tags/**"/>
</javac>
</target>
I set my environment variables for catalina and java as part of my tomcat
start script. And both ANT and Tomcat are using the same compiler as i
understand from ant task documentation. Is there anything else I can do to
reveal the 64k size errors on the method?
KR,
On 26 April 2017 at 11:24, Mark Thomas <ma...@apache.org> wrote:
> On 26/04/17 10:33, Mohammed Manna wrote:
> > Hello,
> >
> > Thanks for suggesting the solutions. This is closer to what I was
> expecting
> > in the original message which I sent in the past. Once again, I
> apologise
> > if I have made any Negative/Reactive comments about Apache no being
> > supportive enough. I have been using various Apache libraries over the
> past
> > 7 years without any issues. But this particular Tomcat upgrade has caused
> > me significant grief in managing large projects where 9/10 systems are
> > legacy code base. I do agree that the JSPs need to be refactored to
> remove
> > any obsolescence. But until your response, I have only received responses
> > where I was asked to upgrade to a different version, but I am more
> curious
> > to find out the root cause for this.
> >
> > Unfortunately, I have to leave with *enablePooling=TRUE, *since it might
> > affect things. I will however try to reconfigure Jasper and use my native
> > Java 1.8.121 to do all the compilation and see how things go.
> >
> > Unless I have misunderstood, Tomcat 8.0.43 will not stop this error but
> > minimise the occurrences of it. Is this correct?
>
> Correct. The error handling code was refactored for 8.0.42 onwards to be
> a little more efficient. It isn't much but if your code is on the border
> line it might be enough to bring it back under the 64k.
>
> Mark
>
>
> >
> >
> > Additionally, thanks to you for putting a lot more attention to it.
> >
> > KR,
> >
> >
> >
> >
> > On 26 April 2017 at 09:58, Mark Thomas <ma...@apache.org> wrote:
> >
> >> On 26/04/17 09:06, Mohammed Manna wrote:
> >>> Hello,
> >>>
> >>> I have emailed and posted a few questions over the web about this, but
> >>> haven't received any helpful response. Since the upgrade to 8.0.39, my
> >> web
> >>> application is failing in various places since the Jasper compiler has
> >> now
> >>> got more debug information (and inturn __jspService method is now
> bigger
> >>> than 64k).
> >>
> >> First a correction. The changes were not made to introduce additional
> >> debug information. The changes introduced additional - specification
> >> required - error handling for tags. The changes were the result of
> >> investigating a reported memory leak [1].
> >>
> >>> I have done the following so far:
> >>>
> >>> 1) Kept mappedFile = TRUE
> >>> 2) Kept suppressSMAP = FALSE
> >>>
> >>> This removes the failure, but now I have lost the JSP debugging
> >> capability.
> >>> Since Apache is not going to provide any support for this, could you
> >> kindly
> >>> assist me with the following:
> >>
> >> First you say Apache isn't going to provide you with any support
> >> (despite this being your first post on this topic) then you ask this
> >> Apache community for that same support. That isn't the best way to
> >> motivate a group of volunteers to help you.
> >>
> >> The initial fix was in 8.0.37.
> >> A regression was fixed in 8.0.40.
> >> A more efficient solution was provided in 8.0.42.
> >> An improved solution for simple tags was in 8.0.43
> >>
> >> The first recommendation is to upgrade to 8.0.43. The more efficient
> >> code introduced in 8.0.42 may help.
> >>
> >> Other configuration settings that can help reduce the size of your JSP
> >> methods include:
> >>
> >> trimSpaces - true
> >> enablePooling - false
> >>
> >> Note the disabling pooling may impact performance. It depends on lot on
> >> the complexity of the tags.
> >>
> >>> 1) How can I identify my JSP pages which are going to have this issue?
> >>> 2) I have tried using ANT build and compiled my JSPs. It simply passes
> >> the
> >>> build, but doesn't report any method size violation. Do you have any
> >>> development mode support that can expose these affected methods.
> >>
> >> Do those pre-compiled JSPs then execute without error?
> >>
> >> Pre-compilation typically uses javac whereas on the fly compilation
> >> typically uses JDT (the Eclipse Compiler). It is possible that
> >> differences in the compilers means that a class compiles with one but
> >> fails with the other - particularly if your code is close to the
> boundary.
> >>
> >> It is possible to configure Jasper to compile JSPs with Ant and javac
> >> (see the compiler init parameter).
> >>
> >> I suggest you try the recommendations above and see how you get on.
> >>
> >>> I appreciate that these are too specific questions, but Tomcat 8.0.39
> >>> upgrade clearly didn't consider legacy systems and has left a massive
> >>> refactoring job to the developers. So, it would be great if you could
> >>> proactively extend "Known Issues" section with these.
> >>
> >> Patches welcome.
> >>
> >> Mark
> >>
> >>
> >> [1] http://tomcat.markmail.org/thread/6jz7wfpcse6oxdgd
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Fwd: Identifying 64k size violation for __jspService methods
loaded by Tomcat
Posted by Mark Thomas <ma...@apache.org>.
On 26/04/17 10:33, Mohammed Manna wrote:
> Hello,
>
> Thanks for suggesting the solutions. This is closer to what I was expecting
> in the original message which I sent in the past. Once again, I apologise
> if I have made any Negative/Reactive comments about Apache no being
> supportive enough. I have been using various Apache libraries over the past
> 7 years without any issues. But this particular Tomcat upgrade has caused
> me significant grief in managing large projects where 9/10 systems are
> legacy code base. I do agree that the JSPs need to be refactored to remove
> any obsolescence. But until your response, I have only received responses
> where I was asked to upgrade to a different version, but I am more curious
> to find out the root cause for this.
>
> Unfortunately, I have to leave with *enablePooling=TRUE, *since it might
> affect things. I will however try to reconfigure Jasper and use my native
> Java 1.8.121 to do all the compilation and see how things go.
>
> Unless I have misunderstood, Tomcat 8.0.43 will not stop this error but
> minimise the occurrences of it. Is this correct?
Correct. The error handling code was refactored for 8.0.42 onwards to be
a little more efficient. It isn't much but if your code is on the border
line it might be enough to bring it back under the 64k.
Mark
>
>
> Additionally, thanks to you for putting a lot more attention to it.
>
> KR,
>
>
>
>
> On 26 April 2017 at 09:58, Mark Thomas <ma...@apache.org> wrote:
>
>> On 26/04/17 09:06, Mohammed Manna wrote:
>>> Hello,
>>>
>>> I have emailed and posted a few questions over the web about this, but
>>> haven't received any helpful response. Since the upgrade to 8.0.39, my
>> web
>>> application is failing in various places since the Jasper compiler has
>> now
>>> got more debug information (and inturn __jspService method is now bigger
>>> than 64k).
>>
>> First a correction. The changes were not made to introduce additional
>> debug information. The changes introduced additional - specification
>> required - error handling for tags. The changes were the result of
>> investigating a reported memory leak [1].
>>
>>> I have done the following so far:
>>>
>>> 1) Kept mappedFile = TRUE
>>> 2) Kept suppressSMAP = FALSE
>>>
>>> This removes the failure, but now I have lost the JSP debugging
>> capability.
>>> Since Apache is not going to provide any support for this, could you
>> kindly
>>> assist me with the following:
>>
>> First you say Apache isn't going to provide you with any support
>> (despite this being your first post on this topic) then you ask this
>> Apache community for that same support. That isn't the best way to
>> motivate a group of volunteers to help you.
>>
>> The initial fix was in 8.0.37.
>> A regression was fixed in 8.0.40.
>> A more efficient solution was provided in 8.0.42.
>> An improved solution for simple tags was in 8.0.43
>>
>> The first recommendation is to upgrade to 8.0.43. The more efficient
>> code introduced in 8.0.42 may help.
>>
>> Other configuration settings that can help reduce the size of your JSP
>> methods include:
>>
>> trimSpaces - true
>> enablePooling - false
>>
>> Note the disabling pooling may impact performance. It depends on lot on
>> the complexity of the tags.
>>
>>> 1) How can I identify my JSP pages which are going to have this issue?
>>> 2) I have tried using ANT build and compiled my JSPs. It simply passes
>> the
>>> build, but doesn't report any method size violation. Do you have any
>>> development mode support that can expose these affected methods.
>>
>> Do those pre-compiled JSPs then execute without error?
>>
>> Pre-compilation typically uses javac whereas on the fly compilation
>> typically uses JDT (the Eclipse Compiler). It is possible that
>> differences in the compilers means that a class compiles with one but
>> fails with the other - particularly if your code is close to the boundary.
>>
>> It is possible to configure Jasper to compile JSPs with Ant and javac
>> (see the compiler init parameter).
>>
>> I suggest you try the recommendations above and see how you get on.
>>
>>> I appreciate that these are too specific questions, but Tomcat 8.0.39
>>> upgrade clearly didn't consider legacy systems and has left a massive
>>> refactoring job to the developers. So, it would be great if you could
>>> proactively extend "Known Issues" section with these.
>>
>> Patches welcome.
>>
>> Mark
>>
>>
>> [1] http://tomcat.markmail.org/thread/6jz7wfpcse6oxdgd
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Fwd: Identifying 64k size violation for __jspService methods
loaded by Tomcat
Posted by Mohammed Manna <ma...@gmail.com>.
Hello,
Thanks for suggesting the solutions. This is closer to what I was expecting
in the original message which I sent in the past. Once again, I apologise
if I have made any Negative/Reactive comments about Apache no being
supportive enough. I have been using various Apache libraries over the past
7 years without any issues. But this particular Tomcat upgrade has caused
me significant grief in managing large projects where 9/10 systems are
legacy code base. I do agree that the JSPs need to be refactored to remove
any obsolescence. But until your response, I have only received responses
where I was asked to upgrade to a different version, but I am more curious
to find out the root cause for this.
Unfortunately, I have to leave with *enablePooling=TRUE, *since it might
affect things. I will however try to reconfigure Jasper and use my native
Java 1.8.121 to do all the compilation and see how things go.
Unless I have misunderstood, Tomcat 8.0.43 will not stop this error but
minimise the occurrences of it. Is this correct?
Additionally, thanks to you for putting a lot more attention to it.
KR,
On 26 April 2017 at 09:58, Mark Thomas <ma...@apache.org> wrote:
> On 26/04/17 09:06, Mohammed Manna wrote:
> > Hello,
> >
> > I have emailed and posted a few questions over the web about this, but
> > haven't received any helpful response. Since the upgrade to 8.0.39, my
> web
> > application is failing in various places since the Jasper compiler has
> now
> > got more debug information (and inturn __jspService method is now bigger
> > than 64k).
>
> First a correction. The changes were not made to introduce additional
> debug information. The changes introduced additional - specification
> required - error handling for tags. The changes were the result of
> investigating a reported memory leak [1].
>
> > I have done the following so far:
> >
> > 1) Kept mappedFile = TRUE
> > 2) Kept suppressSMAP = FALSE
> >
> > This removes the failure, but now I have lost the JSP debugging
> capability.
> > Since Apache is not going to provide any support for this, could you
> kindly
> > assist me with the following:
>
> First you say Apache isn't going to provide you with any support
> (despite this being your first post on this topic) then you ask this
> Apache community for that same support. That isn't the best way to
> motivate a group of volunteers to help you.
>
> The initial fix was in 8.0.37.
> A regression was fixed in 8.0.40.
> A more efficient solution was provided in 8.0.42.
> An improved solution for simple tags was in 8.0.43
>
> The first recommendation is to upgrade to 8.0.43. The more efficient
> code introduced in 8.0.42 may help.
>
> Other configuration settings that can help reduce the size of your JSP
> methods include:
>
> trimSpaces - true
> enablePooling - false
>
> Note the disabling pooling may impact performance. It depends on lot on
> the complexity of the tags.
>
> > 1) How can I identify my JSP pages which are going to have this issue?
> > 2) I have tried using ANT build and compiled my JSPs. It simply passes
> the
> > build, but doesn't report any method size violation. Do you have any
> > development mode support that can expose these affected methods.
>
> Do those pre-compiled JSPs then execute without error?
>
> Pre-compilation typically uses javac whereas on the fly compilation
> typically uses JDT (the Eclipse Compiler). It is possible that
> differences in the compilers means that a class compiles with one but
> fails with the other - particularly if your code is close to the boundary.
>
> It is possible to configure Jasper to compile JSPs with Ant and javac
> (see the compiler init parameter).
>
> I suggest you try the recommendations above and see how you get on.
>
> > I appreciate that these are too specific questions, but Tomcat 8.0.39
> > upgrade clearly didn't consider legacy systems and has left a massive
> > refactoring job to the developers. So, it would be great if you could
> > proactively extend "Known Issues" section with these.
>
> Patches welcome.
>
> Mark
>
>
> [1] http://tomcat.markmail.org/thread/6jz7wfpcse6oxdgd
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Fwd: Identifying 64k size violation for __jspService methods
loaded by Tomcat
Posted by Mark Thomas <ma...@apache.org>.
On 26/04/17 09:06, Mohammed Manna wrote:
> Hello,
>
> I have emailed and posted a few questions over the web about this, but
> haven't received any helpful response. Since the upgrade to 8.0.39, my web
> application is failing in various places since the Jasper compiler has now
> got more debug information (and inturn __jspService method is now bigger
> than 64k).
First a correction. The changes were not made to introduce additional
debug information. The changes introduced additional - specification
required - error handling for tags. The changes were the result of
investigating a reported memory leak [1].
> I have done the following so far:
>
> 1) Kept mappedFile = TRUE
> 2) Kept suppressSMAP = FALSE
>
> This removes the failure, but now I have lost the JSP debugging capability.
> Since Apache is not going to provide any support for this, could you kindly
> assist me with the following:
First you say Apache isn't going to provide you with any support
(despite this being your first post on this topic) then you ask this
Apache community for that same support. That isn't the best way to
motivate a group of volunteers to help you.
The initial fix was in 8.0.37.
A regression was fixed in 8.0.40.
A more efficient solution was provided in 8.0.42.
An improved solution for simple tags was in 8.0.43
The first recommendation is to upgrade to 8.0.43. The more efficient
code introduced in 8.0.42 may help.
Other configuration settings that can help reduce the size of your JSP
methods include:
trimSpaces - true
enablePooling - false
Note the disabling pooling may impact performance. It depends on lot on
the complexity of the tags.
> 1) How can I identify my JSP pages which are going to have this issue?
> 2) I have tried using ANT build and compiled my JSPs. It simply passes the
> build, but doesn't report any method size violation. Do you have any
> development mode support that can expose these affected methods.
Do those pre-compiled JSPs then execute without error?
Pre-compilation typically uses javac whereas on the fly compilation
typically uses JDT (the Eclipse Compiler). It is possible that
differences in the compilers means that a class compiles with one but
fails with the other - particularly if your code is close to the boundary.
It is possible to configure Jasper to compile JSPs with Ant and javac
(see the compiler init parameter).
I suggest you try the recommendations above and see how you get on.
> I appreciate that these are too specific questions, but Tomcat 8.0.39
> upgrade clearly didn't consider legacy systems and has left a massive
> refactoring job to the developers. So, it would be great if you could
> proactively extend "Known Issues" section with these.
Patches welcome.
Mark
[1] http://tomcat.markmail.org/thread/6jz7wfpcse6oxdgd
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org