Jetty 9.3
Java 8
Is org.eclipse.jetty.websocket.client.WebSocketClient thread safe.
Can multiple threads use a single instance of this class to create a websocket session (with the connect method) ?
It's not, from the code here is at least one example why:
The purpose of WebSocketClient is to provide a mean of establishing connections to remote websocket endpoints.
This is achieved by calling connect() method, which returns Future Session. All right, now imagine that
Thread 1 instantiates a WebSocketClient and calls setCookieStore()
Thread 1 calls connect(Object websocket, URI toUri).
Inside connect() Thread 1 executes
ClientUpgradeRequest request = new ClientUpgradeRequest(toUri)
and
request.setRequestURI(toUri)
Thread 2 executes setCookieStore(CookieStore cookieStore)
Then the request created by Thread 1 may have the cookies corresponding to the URI of Thread 2.
In order to ensure thread safety the internal state of the object should de unmodifiable during the whole connection process.
I can't guarantee that WebSocketClient is 100% thread safe, but I can say that it is meant to be thread safe, to a certain extent.
Looking at the source code, we see that the private method initializeClient is synchronized:
private synchronized void initializeClient() throws IOException
and that the connect method is using an Executor:
// Execute the connection on the executor thread
executor.execute(promise);
The documentation of the class says nothing about thread safety, but the call of the synchronized initializeClient method from the connect method and the use of the Executor are clear signs that some form of multi-threading is supported.
== Edit ==
Thread safety is often guaranteed only for certain types of operations. For examples it can be guaranteed only for read operations and not for write operations. This is the role of the documentation to define the conditions of thread safety. The remark of Sergio Montoro is right, if one thread modify the object during its use by another thread, strange things could happens. In the case of WebSocketClient thread safety is certainly at least restricted to the non-modification of the object by other threads, or to the synchronized and concerted modification of the WebSocketClient internal state.
Related
I have a Java/Ninja framework web application sending requests to third party API's via Retrofit API.
I have a thread T1, which is generated from thread pool using Ninja framework Schedule annotation (http://www.ninjaframework.org/apidocs/ninja/scheduler/Schedule.html) .
T1 is polling continously to host1 (example.com).
When another thread say T2 starts a request to the same host (example.com), I want T2 to wait till T1 completes its operations and vice-versa.
I checked out http://square.github.io/okhttp/3.x/okhttp/okhttp3/Dispatcher.html, but looks like the maxRequestsPerHost might not work concurrently.
I tried having a hashMap to modify the hostStatus from each thread and include the status inside synchronzied block, but adding this to multiple methods seems cumbersome.
I'm not sure which concurrency pattern or locking mechanism holds good for this case. Is there a way to add the hostIds to queue or other pattern to implement this behavior.
I'm writing a multithreading application, in my ServerThread.run() method, I use ServerSocket.accept() to receive new incoming connection. Everytime when a new connection arrives, ServerThread creates an other Thread named ClientHandler to handle the connection (Receiving/Sending data), and in my ServerThread, I have a java.util.HashMap<ClientHandler, Socket> to store the references of connected clients and the corresponding sockets.
In my ServerThread, I've implemented a few other public methods, such as shutdown() to stop the server thread, disconnect(int id) to shutdown the connection of a specific client etc. Those methods are usually called by my GUI, from the EDT thread.
I've tested the code, it works, but I'm not sure if it's the best way to do this. I've read lots of Java multithreading tutorials, but they don't add other public methods in their custom java.lang.Thread subclass.
Especially in my ServerThread.run(), I have used the method ServerSocket.accept() which is supposed to be blocking. When I want to shutdown my ServerThread, I have to call ServerSocket.close() to force the thread to stop.
However, when I call for example ServerThread.disconnect(int id) to close the connection of a remote client, it works. Is the ServerThread supposed to be blocking on the accept() method ?
So, my code works, but I don't know why, and I'd like to know if one can add other public methods in a custom subclass of java.lang.Thread ??
Thanks.
The reason you don't add public methods to a Thread class is exactly because this sort of confusion arises - there's an intuition that the Thread class itself 'owns' the execution of those methods, whereas in Java it is -always- the calling thread that owns the execution.
When the EDT thread calls ServerThread.disconnect(id), the code in the disconnect method is being run by the EDT thread, not the ServerThread. The key point here is that the Thread ServerThread, and the Object ServerThread are not quite the same thing, semantically speaking - an Object can't be "blocked" in the same way that a Thread can, the expression doesn't even make sense.
During a job meeting.I have heard that Thread Local is absolutely an anti pattern because new Application servers uses new Thread technologies called new IO.In fact,they told me that the problem with ThreadLocal is that a complete thread must wait for the database query to return a response and that's absolutely a waste of resources(memory as well as CPU).
New developed Thread strategy uses a pool of threads so when a thread is not needed any more it will return to pool.What i have heard is that this new Technology is implemented in new AS such us Jboss,Websphere...(i'm not sure).
Can i use it locally with Apache tomcat for example?(if it's possible documentation on that fact)
ThreadLocal is a side character in your story. What you have heard about is asynchronous request processing, which is helped, among other things, by the NIO library.
In this programming paradigm, you don't get a simple method like
Response processRequest(Request req)
Instead you get
void requestReceived(Request req, Response resp)
and within this method you will usually just start the processing by preparing the back-end request and calling its method which will look like
execute(Query q, ResultCallback cb)
and the framework will call your ResultCallback's method resultReady(Result res) which will contain the query result.
The main point here is that the method requestReceived will return immediately, and will not occupy the thread while the back-end request is being processed at the back-end subsystem.
BTW another name for this style of programming is continuation-passing style or CPS. It is because when you call a function, you don't wait for its return value, but rather pass a callback into it which will be called with the function's result, and which implements the continuation of the total request processing.
How ThreadLocal fits into this
If you have followed what I have said above, it should already be clear to you that in this style of request processing, ThreadLocals are a useless concept because the request processing freely jumps from thread to thread, and in a way which is completely outside of your control.
ThreadLocal has basically nothing to do with databases or ThreadPools/ExecutorServices. ThreadLocal just means that the value stored in it is just visible to the Thread how set it. This doesn't cause any blocking. You must confuse some things there.
ThreadLocal: Stores variable per Thread.
"new IO": They most likely meant the java.nio package. It about reading/writing data without blocking.
Threadpools/Executorservice: Bunch of Threads where you can submit Runnables to. You can use ExecutorServices in any Java application, because they are part of the standard library.
For accessing the database you normally use a dedicated system like C3P0, which manages Threads and database connections
I think that i misunderstand the subject.
Well,i will explain in detail what i have heard.
When using ThreadLocal.If we have for example a query to DataBase or JMS call .The thread must be alive for the response to return (suppose that takes 15 minute for example).The thread will be in a waiting situation waiting for Db to return response.so it's a waste for CPU as well as memory.
New Thread management technology uses a pool of threads.In fact during the waiting time.The thread will be used to server another client.
That's what i have heard.
To Marko Topolnik:What you have exposed is asynchronous calls and it does nothing to do with Threads.
ThreadLocals, thread pools, and new IO can cooperate quite well. All you need is to define thread factory when creating a threadpool so that each new thread would get correct threadlocal value at the moment of creation. This value, for example, can keep a reference to java.nio.channels.Selector singleton. Another thread local variable can hold reference to the thread pool itself, so submitting new tasks to the thread pool can be simplified.
Asynchronous framework https://github.com/rfqu/df4j uses thread locals intensively this way.
I have a Java thread that I start so it keeps listening to a socket (considering the a socket read is blocking a thread is needed).
After the Thread receives the data from the socket it needs to call a method from a class.
Now I have two options to do this:
Declare an interface that is passed to the Thread and implemented in a class. When the thread calls the interface method the implementing classes will run it.
Or I can pass the class instance to the Thread as a parameter and then call the class method.
But I wanted to know if the thread blocks while the method is running.
I suppose so but I'm not sure.
I wanted the thread to have a Socket event behavior. What I mean is to only be responsible for reading the data from the socket and fire functions in the main Class, the one that called the Thread.
Yes, the thread will block while executing the method, so it can not read from the socket at the same time. No information will be lost, the transfer only takes longer and you can get a socket timeout if the computation takes too long.
If your method takes much time to run, you should execute it in another worker thread. I recommend to use an Executor for that.
You have various options :
Make your class a child class of Thread (easier code but you'll merge functionnal part - your main code - with a technical aspect (extending the Thread))
Make your class implements the Runnable interface and start a new thread with that Runnable (i often do like that). So your main code still remains in a overriden run method, but the inheritance tree is up to you (your main class can extend one of your other class)
Keep separated your main code / the thread with two classes (one for your main code, one for the thread), linking the two at your will (remember that if you make an inner thread inside another class, the inner thread can use any final properties, for example).
As stated in other answers, anything happening in your run() method is of course blocking the execution.
As a sidenote, if you're going to deal with threads and sockets, i strongly suggest you to have a look at NIO frameworks like Netty that are just there for this kind of behavior : event driven client/server application through NewIO sockets.
As another sidenote, i often use this pattern :
start an acquisition thread that will catch the event ;
push them in a linkedblockingqueue (queue.offer()) ;
have another thread that shares the same linkedblockingqueue (with queue.take()) : this operation is blocking, the threads will be blocked as long as the queue is empty ;
This is a very simple way to have one thread as "producer", and one thread as "consumer". You can even have various consumers awaiting on the same queue.
But I wanted to know if the thread blocks while the method is running
Yes it does block.
If inside run you call a method to process something it doesn't matter if that is an interface etc as you ask it only matters what does the method actually do
In your case you have only 1 option.
Make sure that you return the control back to your socket listening thread asap.
This can happen by designing/mandating the processing class to handle the processing in a different thread.
Actually your problem is not something new. In event based designs there is the requirement to process the event as fast as possible so as to not block the event queue based flow.
And this is how I would recommend you to design arround. Not use any interface to interact with the listening thread but register an event listener(s).
When an event occurs i.e. your listening thread reads data, it will pass the data as event to your listener(s) at which point of course it will block.
Then you should start a new thread to do the processing and the listening thread can continue with its work
This question already has answers here:
Is ExecutorService (specifically ThreadPoolExecutor) thread safe?
(6 answers)
Closed 4 years ago.
I was working on a Java EE app that took in user requests from a UI and then keyed off a lon workflow asynchronously for each of these requests using ExecutorService (SinglethreadExecutor). Now since i was using a SinglethreadExecutor and because there was genuine need for the requests to be served one at a time, i did not feel the need for thread safety.
Is my understanding correct ?
Recently i had asked a question Issue when executing asynchronous tasks using ExecutorService and the solution to this question was that i make my code thread safe.
I'm looking if any shared resources that I'm using in my code is causing the need for this thread safety but would just like to be sure that my understanding of
the scenario is correct.
FYI, I have implemented my ExecutorService in a servlet as mentioned in Running a background Java program in Tomcat
Your requests will be passed to a different thread to be executed. Even if this thread doesn't access shared data structures, the passing of the request to the thread and the returning of the result need to be properly synchronized.
If you use one of the submit or invoke methods which use a Future object for returning the results, you can assume that the appropriate synchronization is performed. The javadoc for ExecutorService says this:
Memory consistency effects: Actions in a thread prior to the submission of a Runnable or Callable task to an ExecutorService happen-before any actions taken by that task, which in turn happen-before the result is retrieved via Future.get().
In short, if the requests / tasks don't use shared data structures and you use the interface methods provided, then you should be OK.
There are two things that you need to consider when you need to make something "thread safe": When does a thread make data visible to anyone else? When does a thread try to read shared data?
Imagine this situation: Thread A gets the request. It works a bit on it. Then it calls a method foo() that gets the request as a parameter. foo() starts a new thread. The thread puts the reference to the request as a private, non-final field.
In hardware, thread A has copied the request into the L1 cache of the CPU core on which it runs. Since there is no synchronization between the two threads, A has no idea that some other thread might want to read the modified request, so it never flushes the cache (or it does it too late).
This means that thread B will get a stale request object. It won't see any changes made by thread A. As you can imagine, this usually works: If A doesn't change the request, B works. It breaks as soon as you change the code of A and you have a "but it worked yesterday!" situation.
To fix this, you must tell A to flush its caches even if the current version of your code works without it. There are several ways to do it; Stephen C described one. Two other ways:
You can synchronize foo() - A thread must flush when it enters a synchronized block.
Make the request a final field of B - Object graphs referenced via final fields must be completely flushed at the time the type construction has completed (where type == the class which contains the final field).