The following problem has occurred for the second time in few months. The session that tries to open and execute the query using the java driver hangs the particular thread. As a result of this , this particular thread waits forever and causes a thread locking problem. This was resolved using an app server restart . But , one cannot manually intervene for these kind of driver problems . Does anyone have an idea on this?
sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:905)
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1217)
com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:292)
com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)
com.google.common.util.concurrent.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:135)
com.datastax.driver.core.ResultSetFuture.getUninterruptibly(ResultSetFuture.java:181)
com.datastax.driver.core.Session.execute(Session.java:111)
com.datastax.driver.core.Session.execute(Session.java:80)
There is an open ticket on this issue (https://datastax-oss.atlassian.net/browse/JAVA-268). Your best bet would be adding any information you have to that ticket.
Related
I am doing an upgrade from JBPM 3 to 7. The Process Instances runs on a different thread, Sometimes the UI thread needs to access the process Instance via the KIESession. If I try to execute an operation for example sending a signal the UI is blocked until the process instances finish.
I noticed this also happens if I try to about the process Instance, get the status of the the ProcessInstance and get a variable from the process Instance.
I looked further into it and the PersistableRunner.execute() is synchronized .
FYI I am using the per-process Instance strategy.
Is there a way to get around this issue?
A snippet of the thread DUMP:
java.lang.Thread.State: BLOCKED
waiting for JBPM-Processor-5692548#955268 to release lock on <0xb176> (a org.drools.persistence.PersistableRunner)
at org.drools.persistence.PersistableRunner.execute(PersistableRunner.java:400)
at org.drools.persistence.PersistableRunner.execute(PersistableRunner.java:68)
I tried using the singleton strategy
I would like to be able to access a running KieSession from a different threat without being blocked.
How long does the threads take to stop and exit for ActiveMQConsumer? I get a segmentation fault on closing my application. Which I figured out was due to the ActiveMQ threads. If I comment the consumer the issue is no longer present. Currently I am using cms::MessageConsumer in activemq-cpp-library-3.9.4.
I see that the activemq::core::ActiveMQConsumer has isClosed() function that I can use to confirm if the consumer is closed and then move forward with deleting the objects thereby avoiding the segmentation fault. I am assuming this will solve my issue. But I wanted to know what is the correct approach with these ActiveMQ objects to avoid the issues with threads?
I was using the same session with consumer and producer, but when the broker is stopped and started the ActiveMQ reconnect was adding threads. I am not using failover.
So I have separated the session to send and receive and have instantiated connection factory, connection, and session for each separately. This design has no issues until the applications memory was not getting cleaned up due to above segmentation fault.
That's why I wanted to know when should I use cms::MessageConsumer vs ActiveMQConsumer?
The ActiveMQ Website has documentation with examples for the CMS client. I'd suggest reading those and following the example code in how it shuts down the connection and the library resources prior to application shutdown to ensure that resources are cleaned up appropriately.
As with JMS the CMS consumer instance is linked with the thread in the session that created it so if you are closing down a good rule to follow is to close the session to ensure that message deliveries get stopped before you delete anything consumer instances.
I'm using the code here to save the image when creating a new user (Persistence chapter)
saveImageWithoutMonitor
SmalltalkImage current saveSession.
writeMutex
^ WriteMutex ifNil: [WriteMutex := Monitor new]
The problem is saving the image takes time and I suspect Seaside on port 8080 is inaccessible and the browser tries to request the next page and it fails to connect. Any better way to do this? Or configure Seaside to delay the page response?
PS. I remember something you had to configure it in Seaside's config page and it would wait.
During saving the image shutdown and startup lists will be processed during which all sockets will be destroyed, hence the connections are canceled. What we do is to fork the image (with OSProcess) and do the saving in the child process. There's even a method that will do this for you, see OSProcess>>saveImageInBackground.
Side note: there are a couple of race conditions when using a forked process like this. If you're dealing with load, it can happen for instance that the child process "steals" the socket from the parent process, which will result in connection timeouts. To prevent this you would need to close the sockets during the fork operation which isn't an easy problem to solve.
I am trying to create a REST service using a Servlet that lives inside an NSF. The Servlet runs but I noticed that it handles requests one at a time, so if a request is waiting for a database query to finish, all other requests must wait. I know that requests for Servlets on Tomcat or Glassfish get their own thread but that doesn't seem to be happening on the Domino server.
To try and get around this I tried to spawn new threads inside the Servlet but kept getting NotesContext not initialized errors. I searched around and found a project called Threads and Jobs, and intended to use the code there to create a Servlet that spawns new threads and gives the client a requestId and requires them to poll to retrieve the job results, or listen on a port that the server will broadcast on when finished. When I tried to import the project and run it as is, the pages Thread.xsp and Job.xsp rendered but weren't functional. I get the following output in the console:
Thread started
>> Thread running
java.lang.NullPointerException
at com.ibm.domino.xsp.module.nsf.NotesContext.getRunningModule(NotesContext.java:394)
at com.ibm.domino.xsp.module.nsf.NotesContext.checkSignerRightsNonXSP(NotesContext.java:960)
at com.ibm.domino.xsp.module.nsf.ModuleClassLoader$DynamicClassLoader.loadClass(ModuleClassLoader.java:379)
at java.lang.ClassLoader.loadClass(ClassLoader.java:626)
at org.openntf.samples.thread.ThreadSample$MyThread$1.run(ThreadSample.java:86)
at org.openntf.samples.thread.ThreadSample$MyThread$1.run(ThreadSample.java:1)
at com.ibm.domino.xsp.module.nsf.ThreadSessionExecutor$3.run(ThreadSessionExecutor.java:156)
at java.security.AccessController.doPrivileged(AccessController.java:310)
at com.ibm.domino.xsp.module.nsf.ThreadSessionExecutor.run(ThreadSessionExecutor.java:154)
at org.openntf.samples.thread.ThreadSample$MyThread.run(ThreadSample.java:123)
>> Thread running
java.lang.NoClassDefFoundError: lotus/domino/Session
at org.openntf.samples.thread.ThreadSample$MyThread$1.run(ThreadSample.java:86)
at org.openntf.samples.thread.ThreadSample$MyThread$1.run(ThreadSample.java:1)
at com.ibm.domino.xsp.module.nsf.ThreadSessionExecutor$3.run(ThreadSessionExecutor.java:156)
at java.security.AccessController.doPrivileged(AccessController.java:310)
at com.ibm.domino.xsp.module.nsf.ThreadSessionExecutor.run(ThreadSessionExecutor.java:154)
at org.openntf.samples.thread.ThreadSample$MyThread.run(ThreadSample.java:123)
>> Thread stopping
Thread left
You need to design the servlet as OSGi plug-in otherwise it doesn't find the Domino classes. Check this sample for code samples, also have a look at my code for threads and check out Serdar's project on OpenNTF/GitHub
Let us know how it goes.
I'm writing the application, which connects to the DB and repetitively (1 minute interval) reads the data from a database. It's something like RSS feed reader, but with local DB. If the data reading fails, I try to reestablish the connection. I've designed it with TADOConnection and TADOQuery placed on the form (so with no dynamic creation). My aim is to keep the application "alive" from the user's point of view, so I placed the connection and the reading part into a single thread. The question is, how to do it best way ?
My design looks like this:
application start, the TADOConnection and TADOQuery are created along with the form
open connection in a separate thread (TADOConnection)
if the connection is established, suspend the connection thread, start the timer on the form, which periodically resumes another thread for data reading
if the reading thread succeeds, nothing happens and form timer keeps going, if it fails, the thread stops the timer and resume connection thread
Is it better to create TADOConnection or TADOQuery dynamically or it doesn't matter ? Is it better to use e.g. critical section in the threads or something (I have only one access to the component at the same time and only one thread) ?
Thanks for your suggestions
This question is fairly subjective, probably not subjective enough to get closed but subjective any way. Here's why I'd go for dynamically created ADO objects:
Keeps everything together: the code and the objects used to access the code. Using data access objects created on the form requires the Thread to have intimate knowledge of the Form's inner workings, that's never a good idea.
It's safer because you can't access those objects from other threads (including the main VCL thread). Sure, you're not planing on using those connections for anything else, you're not planning on using multiple threads etc, but maybe you'll some day forget about those restrictions.
It's future-proof. You might want to use that same thread from an other project. You might want to add an second thread accesing some other data to the same app.
I have a personal preference for creating data access objects dynamically from code. Yes, an subjective answer to a subjective question.
Run everything in the thread. Have a periodic timer in the thread that opens the DB connection, reads the data, "posts" it back to the main thread, and then disconnects. The thread needs to "sleep" while waiting for the time, e.g. on a Windows even that is signalled by the timer. The DB components, which are local and private to the thread, can be created inside the thread when thread executions starts (on application startup), and freed when thread execution finishes (on application shutdown). This will always work, regardless of whether the DB conncetion is temporarily available or not, and the main thread does not even have to communicate with the "DB thread". It is an architcture that I use all the time and is absolulutely bullet-proof.