What happens when a job does not run because of the disallow annotation.
Is it queued to run after the currently running instance dies?
Is that duplicate "run" of it just thrown away, never to be heard from again?
I've tried testing in code, but my inexperience with the language and library is causing some difficulty.
The additional firings are just delayed (as if no worker thread is available to run them) until the first instance completes. If that causes the next fire time to be missed by more than the scheduler's configured misfire threshold, then the misfire instruction will be applied to the trigger that was blocked.
I'm not exactly sure -- but I think this is equivalent to setting the "synchronized" keyword, which means, the duplicate run will happen after the current running instance dies.
Related
Schedule publishing is failing in magnolia due to below mentioned error. Scheduler is shutdown automatically and its leads to publishing failure.If I restart the author instance then scheduler is up and schedule publishing working fine.
What are the key actions which leads to shutdown the scheduler?
Is there any time frame set to scheduler ?
ERROR info.magnolia.task.schedule.DefaultTaskSchedulerService 30.10.2018 10:28:40 -- Could not schedule job [publish_9e827f8d-89f2-4c61-a0c5-bfe84d5c3a7e].
org.quartz.SchedulerException: The Scheduler has been shutdown.
at org.quartz.core.QuartzScheduler.validateState(QuartzScheduler.java:795)
at org.quartz.core.QuartzScheduler.scheduleJob(QuartzScheduler.java:846)
at org.quartz.impl.StdScheduler.scheduleJob(StdScheduler.java:249)
at info.magnolia.task.schedule.DefaultTaskSchedulerService.schedule(DefaultTaskSchedulerService.java:90)
at info.magnolia.task.DefaultTasksManager.scheduleTask(DefaultTasksManager.java:126)
at info.magnolia.module.workflow.jbpm.workitem.handler.ScheduleTaskWorkItemHandler.executeWorkItem(ScheduleTaskWorkItemHandler.java:49)
at info.magnolia.module.workflow.jbpm.persistence.WorkItemHandlerSystemContextWrapper$1.exec(WorkItemHandlerSystemContextWrapper.java:37)
at info.magnolia.module.workflow.jbpm.persistence.WorkItemHandlerSystemContextWrapper$1.exec(WorkItemHandlerSystemContextWrapper.java:33)
at info.magnolia.context.MgnlContext.doInSystemContext(MgnlContext.java:400)
at info.magnolia.context.MgnlContext.doInSystemContext(MgnlContext.java:378)
at info.magnolia.module.workflow.jbpm.persistence.WorkItemHandlerSystemContextWrapper.executeWorkItem(WorkItemHandlerSystemContextWrapper.java:33)
at org.drools.persistence.jcr.processinstance.JcrWorkItemManager.internalExecuteWorkItem(JcrWorkItemManager.java:76)
at org.jbpm.workflow.instance.node.WorkItemNodeInstance.internalTrigger(WorkItemNodeInstance.java:138)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.trigger(NodeInstanceImpl.java:173)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.triggerNodeInstance(NodeInstanceImpl.java:366)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.triggerConnection(NodeInstanceImpl.java:381)
at org.jbpm.workflow.instance.node.SplitInstance.executeStrategy(SplitInstance.java:117)
at org.jbpm.workflow.instance.node.SplitInstance.internalTrigger(SplitInstance.java:63)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.trigger(NodeInstanceImpl.java:173)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.triggerNodeInstance(NodeInstanceImpl.java:366)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.triggerCompleted(NodeInstanceImpl.java:325)
at org.jbpm.workflow.instance.node.StartNodeInstance.triggerCompleted(StartNodeInstance.java:73)
at org.jbpm.workflow.instance.node.StartNodeInstance.internalTrigger(StartNodeInstance.java:44
> Blockquote
What are the key actions which leads to shutdown the scheduler?
The only action that can make it go down is user initiated shutdown.
Is there any time frame set to scheduler ?
No.
The only reasonable explanation seems to be programatically triggered shutdown.
Since this is not widely reported issue (personally I never heard about it before and I dare to say I've seen most of issues with Magnolia over last couple of years), I'd search your custom code or any community or 3rd party modules you have installed. Perhaps you can also create small scheduled task, e.g. over groovy and have it executed every minute. If the task is only to print the log statement, it should not add too much of the overhead to your instance but would allow you to better pinpoint time when shutdown happens (within minute after last log statement) and perhaps it can also help you find out the cause of shutdown.
Before doing this, you might also want to inspect log file for any exceptions happening prior to you detecting the shutdown, but I presume you have already done this.
Supposed I have an application that can spawn multiple threads if needed for doing tasks ... so nothing special. I use Eclipse to write and debug Java applications. A thread (lets call it "async task") is immediatly respawned after it leaves the run() method (so there is bug and I want to find the reason for this behavior).
My question, if I pause this thread "async task" using the eclipse IDE (debug perspective ..) is there way to find out where this thread was originally started (for example using the Debug view or any other)? Because I want to know who spawns this thread (without making a text search or something like this).
Is there a good way to get this information?
I would set a breakpoint at Thread.start() and enable a condition
Whenever a thread named "async task" is started the condition is evaluated to true and the thread that invokes the start method is paused. Then you can see in the stacktrace from where the call came.
Had a similar problem in production and wrote a litte java agent that logs the stack of every thread start. So the system can run and you get the info live in the log. That helps a lot, when you have many threads. https://github.com/xdev-software/thread-origin-agent
You can't check whether new thread start or not by using debuger since debug will hang your entire JVM.
You can put some logs and check how threads works there.
I have a simple test run of some medium-complexity code that won't terminate, i.e. the main method finishes but the process does not die.
Here is a rundown of the code (which is too long to be pasted here):
ProcessBuilder is used to create a bunch of subprocesses. They all die properly (if you can believe VisualVM).
We use log4j.
The main algorithm runs inside a FutureTask on which run and later get are called.
We don't explicitly use RMI, even though the list of threads seems to suggest so.
Obviously, I can call System.exit(0), but I'd like to know what is amiss here. I have not been able to produce a minimum failing example. Also, I can not identify an obvious culprit from the thread list; maybe you can?
Edit: See here for a thread dump.
Scorpion lead me to the right answer:
RMI Reaper is something like a garbage collector for remote objects, e.g. instances of (subclasses of) UnicastRemoteObject. It is a non-daemon thread and therefore blocks JVM termination if there are still exported objects which can not be cleaned up.
You can explicity force remote objects to be cleaned up in this sense by passing them to UnicastRemoteObject.unexportObject(., true). If you do this on all previously exported objects, RMI Reaper terminates and JVM is free to shut down.
You mention FutureTask. The first thing that comes to my mind is: are you using ExecutorService and forgetting to shut it down?
The second thing that comes to my mind is: are you reading to the end all the streams from the process? I worked with subprocesses long ago, and I don't remember exactly, but. I had problems similar to what you described, and by reading the streams to the end the problem would misteriously disappear!
I'm developing an artificial intelligent program to explore a given space for resources.
I'd like to run multiple scenarios in order to collect data and output to a file.
I used the "multiple runs" option in the gui and i do stop() when one module run is finished (all the resources have been explored). The problem is when It runs the model a second turn, it doesn't work properly.
What I mean is that after running once I always need to kill the application by exiting because the restart option doesn't work properly.
Is there anything that "restart" forgets to do? Because if I exit the application and run it again it works perfectly
Edited so it's more clear:
I use the Repast platform in order to simulate an exploration to Mars. I have 3 kinds of agents, scouting, digging and transporting. They communicate among them to schedule tasks and other things.
The first time I run the simulation everything runs smoothly. And when all the mineral resources of the planet have been explored I restart the model and try again so I can collect data.
The problem is, when I use the "restart" option the Simulation doesn't run well. But if I exit (not restart) and run it again it works fine.
What I'd like to know is if the restart option of Repast GUI misses any steps..
Thanks in advance
PS: If you guys think that it's absolutely necessary I can post some code...but the project is quite big
Don't use Thread.stop() method. It is deprecated. Thread.stop is being deprecated because it is inherently unsafe. Stopping a thread causes it to unlock all the monitors that it has locked. (The monitors are unlocked as the ThreadDeath exception propagates up the stack.) If any of the objects previously protected by these monitors was in an inconsistent state, other threads might view these objects in an inconsistent state. Such objects are said to be damaged. Threads operating on damaged objects can behave arbitrarily, either obviously or not. Unlike other unchecked exceptions, ThreadDeath kills threads silently; thus, the user has no warning that the program may be corrupted. The corruption can manifest itself at an unpredictable time after the damage occurs. Substitute any use of Thread.stop with code that provides for a gentler termination.
http://docs.sun.com/app/docs/doc/805-4031/6j3qv1of1?a=view
Consider thread stopping either via Thread.interrupt() or via setting cancel flag. Look at Java Concurrency in Practice, Section 7.1. Task Cancellation.
Is it possible to kill a Java thread without raising an exception in it?
This is just for testing purposes - I want to simulate a case when the entire computer dies mid-thread.
Note - I saw a deprecated Thread.destroy() method, but the documentation says it never got implemented in the first place.
No. There is the deprecated, 'inherently unsafe' Thread.stop() method, but as its comment emphasizes, things could be left in an deeply corrupted state, and the ThreadDeath Error is still thrown inside the thread.
Sun's explanation of the problems with stop(), which can manifest long after it appears to work, is at:
http://java.sun.com/j2se/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html
Wouldn't killing the JVM process (or yanking the plug) be a better simulation of computer death?
There is no portable method. You might try to call "kill -9" (or your local equivalent) on the whole java process, if you want to suppress the running of finalizers and shutdown hooks.
You won't get any kind of repeatable results out of such a test, but it might be interesting to perform such tests a few thousand times if your program is writing to the file system or a database and might leave inconsistent data structures when being killed.
Or you could... kill the process. (ie, if this is Linux, send a kill -9 signal to the process).
Beware the race issues if you're trying to test something - if you hoping to crash badly - it might only do it once a month if you're particularly unlucky.
What is the point of your test? Java offers no guarantees about what happens on an exit, apart from attempting to run shutdown hooks if the exit is a "clean" one
It sounds akin to trying to test your program's behaviour in the case it goes OutOfMemory; there's nothing you can do about it and no way of telling deterministically what will happen
Is there any reason you can't use Thread.suspend()? It will stop the thread so you can examine the state when the thread is interrupted.
You could also use Thread.stop() although that risks throwing multiple ThreadDeathExceptions. You can wrap it int try/catch/finally blocks, but there are no guarantees.
Thread stop() throws an error in the thread. ThreadDeath
The only way to simulate an application dying mid thread is to call System.exit().
However, this is pretty random so you have to perform the test many times to have any confidence you application behaves correctly no matter where it dies.