Java Scheduleexpression

Asked

Viewed 649 times

3

I’m developing a Nobreaks Supervising Software, I’m using the ScheduleExpression which runs every 5 seconds, followed by code:

@PostConstruct
public void agendarMonitoramento(){


    System.out.println("=================================================================================================");
    System.out.println("Iniciando monitoramento");
    System.out.println("=================================================================================================");

    upsIndividual   = nobreaksEjb.getCadNobreaskMonitoramentoIndividual();


    ScheduleExpression scheduleExpression = new ScheduleExpression().second("*/5").minute("*").hour("*");

    final TimerConfig nobreaksIndividuais = new TimerConfig(NOBREAK_SEM_BANCO_UPS, false);
    timerService.createCalendarTimer(scheduleExpression, nobreaksIndividuais);
    System.out.println("Iniciado...");

}

@Timeout
public void timeout(Timer timer) {

    for (CadNobreak cadNobreak : upsIndividual) {
        tHNobreak.monitorarNobreak(cadNobreak);
    }

}

But I have a problem, identified through Visualvm that these Threads are always active, and are causing a OutOfMemory, below can be seen the number of Active Threads:

inserir a descrição da imagem aqui I wonder why these Threads are not terminated after their execution, and what I can do to solve this problem.

Exception occurred:

03:06:42,426 ERROR [org.jboss.as.ejb3] (EJB default - 7) JBAS014120: Error invoking timeout for timer: [id=2b26961a-daf9-4a2a-aa91-144d43be2190 timedObjectId=prati.supervisorio.nobreaks.prati.supervisorio.nobreaks.ejb.MonitoramentoEjb auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@2fa0052a initialExpiration=Fri Nov 14 00:00:00 BRST 2014 intervalDuration(in milli sec)=0 nextExpiration=Sat Nov 15 02:20:25 BRST 2014 timerState=ACTIVE: javax.ejb.EJBException: JBAS014580: Unexpected Error
    at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:186) [jboss-as-ejb3-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
    at org.jboss.as.ejb3.tx.TimerCMTTxInterceptor.handleExceptionInOurTx(TimerCMTTxInterceptor.java:53) [jboss-as-ejb3-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
    at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:274) [jboss-as-ejb3-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
    at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:339) [jboss-as-ejb3-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
    at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:238) [jboss-as-ejb3-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
    at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [jboss-as-ejb3-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
    at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [jboss-as-ejb3-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
    at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
    at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [jboss-as-ejb3-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
    at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
    at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
    at org.jboss.as.ejb3.timerservice.TimedObjectInvokerImpl.callTimeout(TimedObjectInvokerImpl.java:101) [jboss-as-ejb3-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
    at org.jboss.as.ejb3.timerservice.TimedObjectInvokerImpl.callTimeout(TimedObjectInvokerImpl.java:111) [jboss-as-ejb3-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
    at org.jboss.as.ejb3.timerservice.task.CalendarTimerTask.callTimeout(CalendarTimerTask.java:62) [jboss-as-ejb3-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
    at org.jboss.as.ejb3.timerservice.task.TimerTask.run(TimerTask.java:132) [jboss-as-ejb3-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_67]
    at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_67]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_67]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_67]
    at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_67]
    at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final-redhat-1.jar:2.1.1.Final-redhat-1]
Caused by: java.lang.OutOfMemoryError: Java heap space
java thread jboss scheduler

  • What version of Jboss?

  • Jboss EAP 6.2.0.GA (AS 7.3.0.Final-Redhat-14)

  • Edited, grotesque the number of Threads

2 answers

2

Application servers create a pool threads for execution to prevent the creation and destruction of them at each run.

Threads

If you debug any application server, for example, you’ll see that it creates at least a few dozen threads to meet users' requests when they arrive.

The thread graph is strange because it has about 4,000 threads. This may be an application server error or, more likely, a mistaken system implementation that starts some service with incorrect parameter or multiple times without need.

Check which service most threads belong to find the culprit.

Memoriam

However, this must have nothing to do with your memory problem. To verify the cause of this, we would have to analyze which dependencies you are using and in charge of the process carried out with each execution of the tasks.

The memory graph you’re showing is something normal. The creation of objects over time consumes the memory and when it comes close to the limit the collector (Garbage Collector) performs, removing the objects no longer referenced. So there doesn’t seem to be burst of dynamic memory.

On the other hand, I cannot say the same about the permanent memory (Permgen), where the Strings are internalized and the classes of your application are stored. It is common for this memory to burst when we use many libraries and in projects that are large. If this is the case, it may be necessary to increase the available permanent memory.

Anyway, when we talk about memory problems, it is always good to specify exactly what the problem is, because memory management in Java is not as simple as we think.

If you want to read a little about it, see this other answer here from Sopt.

  • Particularly I found this Thread Pool very high, I will leave my Jboss active from today until tomorrow morning to see what I can capture, on the weekend the error that happened was not very conclusive, I had set up a Queue with the Hornetqueue, but I wasn’t wearing the same thing. I don’t know if this could have affected it. I edited my topic, as can be seen, the error is associated with Thread Pool.

  • @Ederf.Freitas The pool is really big. I hadn’t noticed the greatness. All these threads are from your timer?

  • Yes, at least 90%, because when I deploy without the Timer it drops to about 200 at the most. To reproduce the problem is simple, just use the snippet of code I posted, replacing the content with something else.

1


Problem solved, the high number of Threads was not associated with TimerService of Java, and yes to an object of the SNMP protocol that maintains Threads active, as can be seen below

private void start() throws IOException {
    TransportMapping<?> transport = new DefaultUdpTransportMapping();
    snmp = new Snmp(transport);
    // Do not forget this line!
    transport.listen();

}

And the accumulation of Threads occurred that at each cycle the object was instantiating:

clientSnmp  = new SnmpClient(String.format("udp:%s/161", ipNobreak), timedout);

Keeping all Threads in memory consuming the server’s files, I now maintain a single instance of this active object to avoid redundancies.

Browser other questions tagged java thread jboss scheduler

You are not signed in. Login or sign up in order to post.