We have a few web apps on each server (and a few servers) with a load balancer in front of everything. It’s a convenience to be able to hot deploy an app without turning the entire server off. With the amount of classes that leak we get oom on metaspace very frequently. — Ing. Andrea Vettori Sistemi informativi
> Il giorno 28 feb 2025, alle ore 20:06, Greg Huber <gregh3...@gmail.com> ha > scritto: > > As a matter of interest why would you be repeatedly redeploying your app in > production if you are not using it? > >> On 28/02/2025 15:14, Ing. Andrea Vettori wrote: >> Do I have to open a bug report or is this thread sufficient such that >> someone with look into it ? >> Thank you for your help on this issue >> >>>> On 28 Feb 2025, at 16:09, Greg Huber <gregh3...@gmail.com> wrote: >>> >>> Confirming, the leak is present on v6 struts an on jdk 8,11 and 17. >>> >>> ....At last we can reproduce the problem easily. >>> >>> The following web applications were stopped (reloaded, undeployed), but >>> their >>> classes from previous runs are still loaded in memory, thus causing a memory >>> leak (use a profiler to confirm): >>> /helloworld >>> /helloworld >>> /helloworld >>> >>>> On 28/02/2025 15:02, Ing. Andrea Vettori wrote: >>> >>>> I didn’t touch that setting. >>>> If I check a class file from the war I find it has target 17 (version 61) >>>> >>>> javap -verbose HelloWorldAction.class >>>> >>>> Compiled from "HelloWorldAction.java" >>>> public class org.apache.struts.helloworld.action.HelloWorldAction extends >>>> com.opensymphony.xwork2.ActionSupport >>>> minor version: 0 >>>> major version: 61 >>>> >>>> Are you saying that it doesn’t leak if you compile it with target jdk 17 ? >>>> >>>> Thanks >>>> >>>> >>>>> On 28 Feb 2025, at 15:46, Greg Huber <gregh3...@gmail.com> wrote: >>>>> >>>>> |It seems to me that you’ve compiled struts example war with one jdk and >>>>> are running tomcat with a different one? >>>>> |I did everything with the same jdk version, to be precise it is >>>>> >>>>> The parent has: >>>>> >>>>> <maven.compiler.source>17</maven.compiler.source> >>>>> <maven.compiler.target>17</maven.compiler.target> >>>>> <struts2.version>6.3.0.2</struts2.version> >>>>> >>>>> If I change this to 1.8, and test, (on 8,11,17) I do get the leak when >>>>> undeploying a few times : >>>>> >>>>> The following web applications were stopped (reloaded, undeployed), but >>>>> their >>>>> classes from previous runs are still loaded in memory, thus causing a >>>>> memory >>>>> leak (use a profiler to confirm): >>>>> /helloworld >>>>> /helloworld >>>>> /helloworld >>>>> >>>>> >>>>> On 28/02/2025 14:34, Ing. Andrea Vettori wrote: >>>>>> It seems to me that you’ve compiled struts example war with one jdk and >>>>>> are running tomcat with a different one? >>>>>> I did everything with the same jdk version, to be precise it is >>>>>> >>>>>> openjdk version "17.0.14" 2025-01-21 >>>>>> OpenJDK Runtime Environment Temurin-17.0.14+7 (build 17.0.14+7) >>>>>> OpenJDK 64-Bit Server VM Temurin-17.0.14+7 (build 17.0.14+7, mixed mode, >>>>>> sharing) >>>>>> >>>>>> >>>>>>> On 28 Feb 2025, at 15:28, Greg Huber<gregh3...@gmail.com> wrote: >>>>>>> >>>>>>> Well it only likes jkd17? Should this be jdk8 as its v6? >>>>>>> >>>>>>> java.lang.UnsupportedClassVersionError: >>>>>>> org/apache/struts/helloworld/action/HelloWorldAction has been compiled >>>>>>> by a more recent version of the Java Runtime (class file version 61.0), >>>>>>> this version of the Java Runtime only recognizes class file versions up >>>>>>> to 52.0 (unable to load class >>>>>>> [org.apache.struts.helloworld.action.HelloWorldAction]) >>>>>>> >>>>>>> On 28/02/2025 13:14, Ing. Andrea Vettori wrote: >>>>>>>> I tried to use STRUTS_EXAMPLES_1_1_0 and I get two ApplicationContext >>>>>>>> in memory on jdk17 and tomcat 9.0.100 when doing a redeploy either >>>>>>>> using manager reload or simply coping the war file. >>>>>>>> >>>>>>>> Using tomcat manager I get the following message using the ‘Find >>>>>>>> Leaks’ button: >>>>>>>> >>>>>>>> The following web applications were stopped (reloaded, undeployed), >>>>>>>> but their >>>>>>>> classes from previous runs are still loaded in memory, thus causing a >>>>>>>> memory >>>>>>>> leak (use a profiler to confirm): >>>>>>>> /hello-world >>>>>>>> >>>>>>>> Can anyone confirm that he gets the same results when using the same >>>>>>>> versions ? >>>>>>>> Thanks >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On 28 Feb 2025, at 12:04, Lukasz Lenart<lukaszlen...@apache.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> pt., 28 lut 2025 o 11:55 Greg Huber<gregh3...@gmail.com> napisał(a): >>>>>>>>>> Maybe comparing your test case with the showcase setup may give a >>>>>>>>>> hint >>>>>>>>>> on a config issue. >>>>>>>>>> >>>>>>>>>> @Lukasz do we need a tag for the last javax examples? >>>>>>>>> https://github.com/apache/struts-examples/tree/STRUTS_EXAMPLES_1_1_0 >>>>>>>>> >>>>>>>>> >>>>>>>>> Cheers >>>>>>>>> Łukasz >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail:dev-unsubscr...@struts.apache.org >>>>>>>>> For additional commands, e-mail:dev-h...@struts.apache.org >>>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail:dev-unsubscr...@struts.apache.org >>>>>>>> For additional commands, e-mail:dev-h...@struts.apache.org >>>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail:dev-unsubscr...@struts.apache.org >>>>>>> For additional commands, e-mail:dev-h...@struts.apache.org >>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail:dev-unsubscr...@struts.apache.org >>>>>> For additional commands, e-mail:dev-h...@struts.apache.org >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>> For additional commands, e-mail: dev-h...@struts.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
