tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: Fwd: Identifying 64k size violation for __jspService methods loaded by Tomcat
Date Mon, 01 May 2017 21:11:02 GMT
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" <markt@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 <markt@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 <markt@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


Mime
View raw message