I'm try to run LDA algorithm using mallet library. When I try to run LDA with a set of parameters it's OK but with another set I have this error:
09-Oct-2014 23:50:24.354 INFO [http-nio-8084-exec-127] cc.mallet.topics.ParallelTopicModel.estimate <50> LL/token: -8.73265
09-Oct-2014 23:50:24.657 INFO [http-nio-8084-exec-127] null.null [beta: 0.00795]
09-Oct-2014 23:50:24.657 INFO [http-nio-8084-exec-127] null.null <60> LL/token: -8.6299
09-Oct-2014 23:50:24.957 INFO [http-nio-8084-exec-127] cc.mallet.topics.ParallelTopicModel.estimate <70> LL/token: -8.61982
09-Oct-2014 23:50:25.019 INFO [http-nio-8084-exec-127] null.null [beta: 0.00583]
09-Oct-2014 23:50:25.263 INFO [http-nio-8084-exec-127] cc.mallet.topics.ParallelTopicModel.estimate <80> LL/token: -8.89656
09-Oct-2014 23:50:25.402 INFO [http-nio-8084-exec-127] null.null [beta: 0.00484]
java.lang.ArrayIndexOutOfBoundsException: -1 at
cc.mallet.topics.WorkerRunnable.sampleTopicsForOneDoc(WorkerRunnable.java:489) at
cc.mallet.topics.WorkerRunnable.run(WorkerRunnable.java:275) at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at
java.util.concurrent.FutureTask.run(FutureTask.java:266) at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at
java.lang.Thread.run(Thread.java:745) java.lang.ArrayIndexOutOfBoundsException: -1 at
cc.mallet.topics.WorkerRunnable.sampleTopicsForOneDoc(WorkerRunnable.java:489) at
cc.mallet.topics.WorkerRunnable.run(WorkerRunnable.java:275) at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at
java.util.concurrent.FutureTask.run(FutureTask.java:266) at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at
java.lang.Thread.run(Thread.java:745)
My code look like:
try{
//call some function from library
} catch(Exception e){
System.out.println("LDA Exception")
}
How can catch exception caused by external jars? I have reed this question but it doesn't work for me. Any Idea?
EDIT:
My project is an restful webservice which it run on apache tomcat Server. I try to call lda algorithm in dopost function.
EDIT 2
Mallet is an open source library. So I tried to read code and I found the below code.
public class ParallelTopicModel implements Serializable {
int numThreads = 2;
public void estimate() throws IOException {
WorkerRunnable[] runnables = new WorkerRunnable[numThreads];
for (int thread = 0; thread < numThreads; thread++) {
runnables[thread] = new WorkerRunnable(numTopics, alpha, alphaSum, beta,
random, data, runnableCounts,
runnableTotals, offset, docsPerThread);
//some code
}
}
}
public class WorkerRunnable implements Runnable {
public void run() {
try {
//some code
} catch (Exception e) {
e.printStackTrace();
}
}
}
My webservice:
#POST
#Produces("application/xml")
public String getXml(#FormParam("xmlinput") String xmlinput) throws Exception {
try {
//call estimate function in ParallelTopicModel class
//return an xml;
} catch (Exception e) {
return "<?xml version=\"1.0\" encoding=\"UTF-8\"?>" + "<modelingOutput>null</modelingOutput>";
}
So how can handle exceptions whiche produce WorkRunnable class in my web service. I want to ruturn an xml look like
`null
I have read a lot of questions like this and this but I don't found solution
The problem here is not that the call is to an external jar. Exceptions thrown by any method in your chain of calls, no matter where the actual class's bytecode is stored, are caught at the first catch block up the chain.
The problem you have here is that the exception occurs in a different thread. If you start a separate thread from your code, the exceptions in that thread are not passed on to your thread. As far as your code is concerned, that call has completed. If the code in the other thread doesn't catch them, they'll be caught by that thread's exception handler, if there is such a handler.
Runtime errors are usually caused by bad input, so the usual strategy to avoid them would be to understand why your parameters cause the array index in that method to be negative, and then make sure you never pass such parameters to that method.
If that is impossible, you may create an exception handler for the thread. This would work only if you are the one in control of creating the thread and you can set the handler in it.
You may want to look at this question for more about handling exceptions in threads.
Edit:
Since their WorkerRunnable code seems to catch all exceptions (and print a stack trace), there is no way to catch them yourself. You can do one of two things:
As I said above, check what parameters you passed caused the array out of bounds error, and avoid those conditions. Use an if statement and if the parameters are bad, print your <modelingOutput>null</modelingOutput> output - without running the modeling in the first place.
Use their source, change their catch clause to something that sets a variable that tells you there was an exception, compile it and use that jar instead of theirs. That's what Open Source is for. You may want to communicate with the maintainers of that library and tell them that it would be nice if they added a way to detect if an exception was caused by one of the sub threads.
Related
Context
I have a webservice writing a test id in a queue. Then, a listener reads the queue, searches the test and starts it. During those steps, it writes updates of the test in the database in order to be shown to the user. To be more precise: the test is launched in a docker container and at the end of it, I want to update the status of the test to FINISHED. For that, I use the docker java library with a callback.
Problem
When it comes to call the callback, I receive multiple error messages on the call to update the test (but it happens only once, if I try twice the second time works, but it still writes a lot of error messages from the transaction manager).
Here are the error messages logged:
2020-11-20 09:20:43,639 WARN [docker-java-stream--1032099154] (org.jboss.jca.core.connectionmanager.listener.TxConnectionListener) IJ000305: Connection error occured: org.jboss.jca.core.connectionmanager.listener.TxConnectionListener#600268e6[state=NORMAL managed connection=org.jboss.jca.adapters.jdbc.local.LocalManagedConnection#236f1a69 connection handles=1 lastReturned=1605860423264 lastValidated=1605860242146 lastCheckedOut=1605860443564 trackByTx=true pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool#2efb0d3b mcp=SemaphoreConcurrentLinkedQueueManagedConnectionPool#3e8e7a62[pool=ApplicationDS] xaResource=LocalXAResourceImpl#482fdad2[connectionListener=600268e6 connectionManager=4c83f895 warned=false currentXid=null productName=Oracle productVersion=Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
Version 18.3.0.0.0 jndiName=java:/ApplicationDS] txSync=TransactionSynchronization#1387480544{tx=Local transaction (delegate=TransactionImple < ac, BasicAction: 0:ffffac110002:-50a6b0bf:5fb6bdb9:73db4 status: ActionStatus.ABORTING >, owner=Local transaction context for provider JBoss JTA transaction provider) wasTrackByTx=true enlisted=true cancel=false}]: java.sql.SQLRecoverableException: IO Error: Socket read interrupted
2020-11-20 09:20:43,647 INFO [docker-java-stream--1032099154] (org.jboss.jca.core.connectionmanager.listener.TxConnectionListener) IJ000302: Unregistered handle that was not registered: org.jboss.jca.adapters.jdbc.jdk8.WrappedConnectionJDK8#4f3c1cb2 for managed connection: org.jboss.jca.adapters.jdbc.local.LocalManagedConnection#236f1a69
2020-11-20 09:20:43,656 WARN [docker-java-stream--1032099154] (com.arjuna.ats.jta) ARJUNA016031: XAOnePhaseResource.rollback for < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110002:-50a6b0bf:5fb6bdb9:73db4, node_name=1, branch_uid=0:ffffac110002:-50a6b0bf:5fb6bdb9:73db8, subordinatenodename=null, eis_name=java:/ApplicationDS > failed with exception: org.jboss.jca.core.spi.transaction.local.LocalXAException: IJ001160: Could not rollback local transaction
Caused by: org.jboss.jca.core.spi.transaction.local.LocalResourceException: IO Error: Socket read interrupted
at org.jboss.ironjacamar.jdbcadapters#1.4.22.Final//org.jboss.jca.adapters.jdbc.local.LocalManagedConnection.rollback(LocalManagedConnection.java:139)
...
Caused by: java.sql.SQLRecoverableException: IO Error: Socket read interrupted
at com.oracle.jdbc//oracle.jdbc.driver.T4CConnection.doRollback(T4CConnection.java:1140)
...
Caused by: java.io.InterruptedIOException: Socket read interrupted
at com.oracle.jdbc//oracle.net.nt.TimeoutSocketChannel.handleInterrupt(TimeoutSocketChannel.java:258)
...
Explanation
At the beginning, I thought about a connection problem, maybe the the transaction is no more available at the callback time (because the docker run took too long), maybe it has to be invalidated.
But at the end, as written in the console, it came from an interruption of the thread when it tries to acquire the lock to update the test and I discovered where this interruption came from: I took a look at the method executeAndStream in DefaultInvocationBuilder from the docker java library and I discovered this:
Thread thread = new Thread(() -> {
Thread streamingThread = Thread.currentThread();
try (DockerHttpClient.Response response = execute(request)) {
callback.onStart(() -> {
streamingThread.interrupt();
response.close();
});
sourceConsumer.accept(response);
callback.onComplete();
} catch (Exception e) {
callback.onError(e);
}
}, "docker-java-stream-" + Objects.hashCode(request));
thread.setDaemon(true);
thread.start();
And here it is, the closable given to onStart interrupts the thread. After that, I discovered in the method onComplete from ResultCallbackTemplate (that I was extending for my callback) a close on that closable:
#Override
public void onComplete() {
try {
close();
} catch (IOException e) {
throw new RuntimeException(e);
}
}
Resolution
The problem finally came from the following code I wrote:
#Override
public void onComplete() {
super.onComplete();
updateTest(FINISHED);
}
I was calling the onComplete method from the parent without knowing what is does and as usual, first before doing anything else. To correct that, I only had to call the super method at the end:
#Override
public void onComplete() {
updateTest(FINISHED);
super.onComplete();
}
While reading jvm specification I came across exception (2.10 Exceptions)
Most exceptions occur synchronously as a result of an action by the
thread in which they occur. An asynchronous exception, by contrast,
can potentially occur at any point in the execution of a program ...
What are the differences between the two types ?
Keeping reading, the specification gives and example of an asynchronous exception
An asynchronous exception occurred because: – The stop method of class
Thread or ThreadGroup was invoked, or – An internal error occurred in
the Java Virtual Machine implementation.
But what makes stop method of a class thread special in this regard ?
Can you explain the differences between the two and give some examples of them, other than the given ones ?
The stop method can be called from another thread which could leave the data altered by the thread stopped in an inconsistent state.
For this reason Thread.stop() is being removed. I suggest you not use it.
Can you explain the differences between the two and give some examples of them, other than the given ones
The difference is that an asynchronous exception is triggered by another thread at any point in the code.
They should not happen under normal operation.
A specific implementation of the JVM could have other errors but there is not exhaustive list.
There isn't much you can do about except shutdown gracefully.
Here's an example showing the two types of exception. Consider the following code snippets, which show the two kinds of exception being raised, and handled:
public static void main(String[] args) throws Exception {
try {
syncException();
} catch (RuntimeException re) {
System.out.println("-1-");
re.printStackTrace();
}
CompletableFuture<Void> f = null;
try {
f = asyncException();
} catch (RuntimeException ex) {
System.out.println("-2-" + Thread.currentThread().getName());
ex.printStackTrace();
}
try {
f.get();
} catch (Exception ex) {
System.out.println("-3-");
ex.printStackTrace();
}
}
A synchronous exception
private static void syncException() {
throw new RuntimeException("Sync exception #" + Thread.currentThread().getName());
}
And an asynchronous exception - raised in a different thread from the calling code:
private static CompletableFuture<Void> asyncException() {
return CompletableFuture.runAsync(() -> {
throw new RuntimeException("Async exception #" + Thread.currentThread().getName());
}, Executors.newFixedThreadPool(1));
}
Now, when that code is executed, the following stack traces are produced:
The synchronous exception's stack trace:
-1-
java.lang.RuntimeException: Sync exception #main
at stackoverflow.Main.syncException(Main.java:34)
at stackoverflow.Main.main(Main.java:11)
Note that -2- was not printed, because the exception was asynchronous. See the third catch block's stack trace for how asynchronous exceptions are handled. Note that the thread in which the exception was raised is different from the one printing the stack trace:
-3-
java.util.concurrent.ExecutionException: java.lang.RuntimeException: Async exception #pool-1-thread-1
at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357)
at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1895)
at stackoverflow.Main.main(Main.java:26)
Caused by: java.lang.RuntimeException: Async exception #pool-1-thread-1
at stackoverflow.Main.lambda$0(Main.java:39)
at java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1626)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
An asynchronous exception, by contrast, can potentially occur at any point in the execution of a program ...
Just a comment on this: you'll notice that the code in thread pool-1-thread-1 could raise the exception any time of the main thread's execution. This is probably relative among threads. But in this example, the main thread being the main programe execution, we can say that the "Async exception #pool-1-thread-1" exception occurred asynchronously.
I'm using hystrix 1.3.7 and my hystrix command has a fallback method defined as well. So it is setup as follows:
public final Optional<ImageData> run() throws Exception {
// does api call to get resized image from a service
}
#Override
public final Optional<ImageData> getFallback() {
// falls back to processing the image locally.
}
However, I have realized that some times (not all times) when the timeout occurs for Hystrix, it seems like it does not execute the logic in getFallback method and throws HsytrixRuntimeException. Here is the stacktrace:
com.netflix.hystrix.exception.HystrixRuntimeException: imageResize timed-out and fallback failed.
at com.netflix.hystrix.AbstractCommand.handleTimeoutViaFallback(AbstractCommand.java:980)
at com.netflix.hystrix.AbstractCommand.access$500(AbstractCommand.java:59)
at com.netflix.hystrix.AbstractCommand$12.call(AbstractCommand.java:595)
at com.netflix.hystrix.AbstractCommand$12.call(AbstractCommand.java:587)
at rx.internal.operators.OperatorOnErrorResumeNextViaFunction$1.onError(OperatorOnErrorResumeNextViaFunction.java:77)
at rx.internal.operators.OperatorDoOnEach$1.onError(OperatorDoOnEach.java:70)
at rx.internal.operators.OperatorDoOnEach$1.onError(OperatorDoOnEach.java:70)
at com.netflix.hystrix.AbstractCommand$HystrixObservableTimeoutOperator$1.run(AbstractCommand.java:1121)
at com.netflix.hystrix.strategy.concurrency.HystrixContextRunnable$1.call(HystrixContextRunnable.java:41)
at com.netflix.hystrix.strategy.concurrency.HystrixContextRunnable$1.call(HystrixContextRunnable.java:37)
at com.netflix.hystrix.strategy.concurrency.HystrixContextRunnable.run(HystrixContextRunnable.java:57)
at com.netflix.hystrix.AbstractCommand$HystrixObservableTimeoutOperator$2.tick(AbstractCommand.java:1138)
at com.netflix.hystrix.util.HystrixTimer$1.run(HystrixTimer.java:99)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Could this be because hystrix is not configured properly? Any help would be appreciated.
From the error logs I understand that your run() method got failed and the fall back is invoked. The logic you have inside the fallback also seems to get failed. Recommendation is that, fallback should be coded in such a way that it never gets failed. Please check your fallback code if that is failing. Either handle the failure inside fallback or simply move the logic somewhere out of fallback.
I have code that looks like this:
public void handleRequests() {
ZMQ.Poller items = new ZMQ.Poller(1);
items.register(clientEndpoint, ZMQ.Poller.POLLIN);
while (!Thread.currentThread().isInterrupted()) {
byte[] message;
items.poll(); // this is the line that throws exception.
if (items.pollin(0)) {
message = clientEndpoint.recv(0);
}
}
}
It works fine when i call it directly:
foo.handleRequests();
but it fails regularly with assertion errors if it is run in a new thread:
final Runnable listener = worldviewServer::handleRequests;
Executors.newSingleThreadExecutor().execute(listener);
The stack trace I get is shown below:
Exception in thread "pool-6-thread-1" java.lang.AssertionError
at zmq.Mailbox.recv(Mailbox.java:113)
at zmq.SocketBase.process_commands(SocketBase.java:820)
at zmq.SocketBase.getsockopt(SocketBase.java:258)
at zmq.PollItem.readyOps(PollItem.java:107)
at zmq.ZMQ.zmq_poll(ZMQ.java:708)
at zmq.ZMQ.zmq_poll(ZMQ.java:600)
at org.zeromq.ZMQ$Poller.poll(ZMQ.java:1618)
at org.zeromq.ZMQ$Poller.poll(ZMQ.java:1592)
at com.tracelink.worldview.server.Head.handleRequests(Head.java:68)
at com.tracelink.worldview.server.WorldviewServer.handleRequests(WorldviewServer.java:236)
at com.tracelink.worldview.server.fsm.EnablingAction$$Lambda$12/404648734.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
I'm using Java 8 with JeroMQ 0.3.5-SNAPSHOT
ZMQ sockets are not threadsafe. You have some limited ability to create a socket in one thread and then use it in another, but I'm guessing that the unseen code will branch off into multiple threads all attempting to use the socket at the same time. That's a ZMQ no-no. Generally, you should be creating sockets in the threads they'll be used in.
ZMQ contexts are threadsafe.
I have a task scheduler implemented in my application. Basically, what i do is schedule some task's to be executed 4 times in a day (like 6 in 6 hours), so the system schedules it to: 00:00, 06:00, 12:00, 18:00.
Ok, i have a class (FlowJobController) which extends the Thread class and in the run() implementation i keep sleeping the thread in 60 to 60 seconds, so it's executed again to check if there's any task to be executed. If true, i run my Job.
Basically the main part it:
rSet = pStmt.executeQuery();
while (rSet.next()) {
long jobId = rSet.getLong("trf_codigo");
String ruleName = rSet.getString("reg_nome");
String ruleParameters = rSet.getString("trf_regra_parametros");
Job job = new Job();
job.setId(jobId);
job.setRuleName(ruleName);
job.setParameters(Functions.stringToList(ruleParameters, "\n"));
FlowJob flowJob = new FlowJob(this, job);
flowJob.start();
}
} catch (Exception ex) {
logger.error(WFRSystem.DEFAULT_USER, system.getCode(), ex);
} finally {
try {
DBConnection.close(pStmt);
DBConnection.close(rSet);
// executede 60 in 60 sec
Thread.sleep(60 * 1000);
} catch (InterruptedException ex) {
logger.error(WFRSystem.DEFAULT_USER, system.getCode(), ex);
}
}
The thing is: When the pStmt.executeQUery() returns records to be executed, it goes into the while and the error appears into the line: Job job = new Job();
The error is:
Exception in thread "FlowJobController" java.lang.NoClassDefFoundError: wfr/com/Job
at wfr.com.FlowJobController.run(FlowJobController.java:112)
Before this error i got this error:
25/09/2012 12:00:09 org.apache.catalina.loader.WebappClassLoader loadClass
INFO: Illegal access: this web application instance has been stopped already. Could not load wfr.com.Job.
The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.
java.lang.IllegalStateException
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1566)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1526)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at wfr.com.FlowJobController.run(FlowJobController.java:112)
The FlowJobController.java:112 is the Job job = new Job();
What am i doing wrong?
The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.
If you are saying that your code deliberately threw the IllegalStateException exception, then that is the likely cause of the subsequent problems. If you throw an uncheck exception in static initialization, and that exception propagates, then the class initialization fails, and the class (and all classes that depend on it) are unusable. In this case, it looks like it also caused the webapp to be stopped.
If this is the problem, the solution is "don't do that". Fix whatever is causing the exception to be thrown.
The other possibility is that this is simply a missing class problem:
Well, that sounds not possible (to not be in the war) since i'm running into the eclipse environment and it's in the class folder directory and no errors is shown about not finding those classes...
The class loader won't be looking in the Eclipse classes folder. It will be looking in the webapp directory on your web container (Tomcat, Jetty, whatever).