I intend to test a Server class to see how it handles concurrent reads and writes using direct calls to the server class, nothing more fancy. I have a Server API that has two functions.
int fetch(int key);
void push(int key, int value);
How do I create multiple clients making calls to the server? Do I just start multiple threads of a Client class implementing Runnable that call the functions using a static server variable within run()?
Yes, exactly, you should have multiple clients running at the same time on different threads, and they should call the same server object.
Note that with this kind of testing there is no guarantee that you find all the bugs. You should still reason about the thread safety of your code. Possibly you could also use more sophisticated concurrent testing frameworks like multithreadedtc
Related
I am trying to integrate QFJ into a single-threaded application. At first I was trying to utilize QFJ with my own TCP layer, but I haven't been able to work that out. Now I am just trying to integrate an initiator. Based on my research into QFJ, I would think the overall design should be as follows:
The application will no longer be single-threaded, since the QFJ initiator will create threads, so some synchronization is needed.
Here I am using an SocketInitiator (I only handle a single FIX session), but I would expect a similar setup should I go for the threaded version later on.
There are 2 aspects to the integration of the initiator into my application:
Receiving side (fromApp callback): I believe this is straightforward, I simply push messages to a thread-safe queue consumed by my MainProcessThread.
Sending side: I'm struggling to find documentation on this front. How should I handle synchronization? Is it safe to call Session.sendToTarget() from the MainProcessThread? Or is there some synchronization I need to put in place?
As Michael already said, it is perfectly safe to call Session.sendToTarget() from multiple threads, even concurrently. But as far as I see it you only utilize one thread anyway (MainProcessThread).
The relevant part of the Session class is in method sendRaw():
private boolean sendRaw(Message message, int num) {
// sequence number must be locked until application
// callback returns since it may be effectively rolled
// back if the callback fails.
state.lockSenderMsgSeqNum();
try {
.... some logic here
} finally {
state.unlockSenderMsgSeqNum();
}
Other points:
Here I am using an SocketInitiator (I only handle a single FIX session), but I would expect a similar setup should I go for the threaded version later on.
Will you always use only one Session? If yes, then there is no use in utilizing the ThreadedSocketInitiator since all it does is creating a thread per Session.
The application will no longer be single threaded, since the QFJ initiator will create threads
As already stated here Use own TCP layer implementation with QuickFIX/J you could try passing an ExecutorFactory. But this might not be applicable to your specific use case.
Can anyone please tell me how to create a server and client (both) in a single file?
I searched the net and came to know that it is possible using the threads. I am not familiar with threads. I am trying to implement a peer to peer application. At some point, the peer has to behave as server and client. Can anyone please give a sample code or direct me to a good source?
Put simply, threads are parallel workflows that execute your code. So if you have two instances of threads, you can have one of them execute method A, and one of them execute method B, and both will occur concurrently. The art and science of writing concurrent code is very advanced and takes a long while to master.
However it's very easy to begin. For each piece of code you want to run separately, you create a class extending Thread, and put the code to be run in the overridden run() method. In your case, that could be a class Client extends Thread and class Server extends Thread. Then, from the code initiating the threads (maybe your public static void main() method?) you instantiate both classes, and execute their start() method. Note that start() returns immediately; the code in run() then executes in concurrency. So
a.start();
b.start();
would actually return immediately and then both a and b are running in parallel.
Read this post. This post uses a Java UDP Server and Client code which connects with a Python UDP Client and Server code.
You can make use of Java UDP Server and Client code.
I have multiple client handler threads, these threads need to pass received object to a server queue and the sever queue will pass another type of object back to the sending thread. The server queue is started and keeps running when the server starts.I am not sure which thread mechanism to use for the client handler threads notified an object is sent back. I don't intend to use socket or writing to a file.
If you wanted to do actual message passing take a look at SynchronusQueue. Each thread will have reference to the queue and would wait until one thread passed the reference through the queue.
This would be thread safe and address your requirements.
Though if you are simply looking to have threads read and write a shared variable you can use normalocity's suggestion though it's thread-safety depends on how you access it (via sychronized or volatile)
As far as making objects accessible in Java, there's no difference between multi-thread and single-thread. You just follow the scope rules (public, private, protected), and that's it. Multiple threads all run within the same process, so there isn't any special thread-only scope rules to know about.
For example, define a method where you pass the object in, and make that method accessible from the other thread. The object you want to pass around simply needs to be accessible from the other thread's scope.
As far as thread-safety, you can synchronize your writes, and for the most part, that will take care of things. Thread safety can get a bit hairy the more complicated your code, but I think this will get you started.
One method for processing objects, and producing result objects is to have a shared array or LinkedList that acts as a queue of objects, containing the objects to be processed, and the resulting objects from that processing. It's hard to go into much more detail than that without more specifics on what exactly you're trying to do, but most shared access to objects between threads comes down to either inter-thread method calls, or some shared collection/queue of objects.
Unless you are absolutely certain that it will always be only a single object at a time, use some sort of Queue.
If you are certain that it will always be only a single object at a time, use some sort of Queue anyway. :-)
Use a concurrent queue from the java.util.concurrent.*.
why? Almost guaranteed to provide better general performance than any thing hand rolled.
recommendation: use a bound queue and you will get back-pressure for free.
note: the depth of queue determines your general latency characteristics: shallower queues will have lower latencies at the cost of reduced bandwidth.
Use Future semantics
why? Futures provide a proven and standard means of getting asynchronous result.
recommendation: create a simple Request class and expose a method #getFutureResponse(). The implementation of this method can use a variety of signaling strategies, such as Lock, flag (using Atomic/CAS), etc.
note: use of timeout semantics in Future will allow you to link server behavior to your server SLA e.g. #getFutureResponse(sla_timeout_ms).
A book tip for if you want to dive a bit more into communication between threads (or processes, or systems): Pattern-Oriented Software Architecture Volume 2: Patterns for Concurrent and Networked Objects
Just use simple dependency injection.
MyFirstThread extends Thread{
public void setData(Object o){...}
}
MySecondThread extends Thread{
MyFirstThread callback;
MySecondThread(MyFirstThread callback){this.callback=callback)
}
MyFirstThread t1 = new MyFirstThread();
MySecondThread t2 = new MySecondThread(t1);
t1.start();
t2.start();
You can now do callback.setData(...) in your second thread.
I find this to be the safest way. Other solutions involve using volatile or some kind of shared object which I think is an overkill.
You may also want to use BlockingQueue and pass both of those to each thread. If you plan to have more than one thread then it is probably a better solution.
I have two classes in short here they are:
public final class ServerMain
{
static List<Table> s_AvailableGameTables = new Vector<Table>();
static List<Table> s_OccupiedGameTables = new Vector<Table>();
static List<ServerThread> s_PlayersOnServer = new Vector<ServerThread>();
...
}
class ServerThread extends Thread{
...}
ServerMain is the server itself, and it manages the ServerThreads by allocating a new ServerThread for each user who has just connected to the ServerMain.
My questions are simple:
When I'm currently running in the specific ServerThread and I want to access some static lists on the serverMain and to update them how can I do that , if I've already "left" the area of the ServerMain while being in the specific thread which runs in the background.
Is the only way is to hold a reference from each serverthread to papa ServerMain?
Maybe it can cause some problems as if at the same time two areas of the code can update the same list the ServerMain itself and the ServerThread which now knows who is the big boss around?
General question: does sockets programming means UDP or TCP?
I'd like to hear some good advice. Thanks in advance.
For #1, you wouldn't need an instance to access static members of ServerMain, assuming they are accessible (e.g. they are public) you can access them as ServerMain.MyVar.
For #2, yes, you would need to look into using the synchronized statement to prevent multiple threads for writing to the list at the same time, or use a thread safe list implementation.
For #3, the term 'sockets programming' can refer to either UDP or TCP. Which kind of socket you use will depend on what kind of app you are implementing.
1) That is one of the possibilities. In general, when you need to access another object methods, the best way is to keep the reference (directly or indirectly). Yet, as it is supposed that you'll only have a ServerMain object, you could try to declare static methods or use the singleton construction (private constructor, you can only access a getInstance() static method that returns a shared object).
2) Synchronization of access between threads is a lengthy subject and many books have been written about it. The simplest way is to use a synchronized method (or block) and do all race sensitive commands inside. But be conscient that this probably these synchronized blocks will later become your main bottleneck. When you have more practice, study java synchronization methods.
3) As others java stated, you just open a socket that listens to a protocol in a given port number. You can decide if you want it to be UDP or TCP. Of course, keep in mind that with UDP maybe the message that you receive won't be complete, so it will have to be dealt with by your code.
No, you can reference it like 'normal'. In the sense that there is no syntactic changes for actually referencing things from a different thread rather than a different object. Now, you may need to synchronize access to it, but I don't really see that as changing how you reference things.
Synchronize the list (preferably use the java.util.concurrent package). Make sure that the Tables themselves are thread-safe as well.
Neither, a socket uses a transport protocol, but it could be UDP, TCP, or whatever else. To clarify, you can't determine what transport protocol is being used just by saying you're using a socket; you'd have to specify which protocol you're actually using.
You can access as normal if you use a synchronized list (i.e., Vector, one of the lists from the java.util.concurrent package, or if it's a better fit Collections.synchronizedList(list)).
Vector is already 'synchronized', but be aware that you have to synchronize transactions manually (i.e., synchronized (vector) { vector.add(..); vector.remove(..); }). The synchronisation it employs by default essentially stops list method calls from interrupting currently-executing user-defined transactions and currently-executing method calls on the list. I'd advise using Collections.synchronizedList(list) instead of Vector, although they both do the same job, really.
ServerSocket / Socket is TCP, DatagramSocket is UDP.
1) That would be a way and probably a preferred way, though not necessarily the only way.
Also, the reference does not need to be owned by the ServerThread. Since ServerMain is likely a singleton, I have found in situations like this that it makes sense to give that Singleton a static variable which references itself. Then, from any ServerThread, you could do
class ServerThread extends Thread
{
public void someMethod()
{
ServerMain.serverMain.whatever();
}
}
2) Yes, that will cause problems. Read the Java Concurrency Trail, specifically the parts about synchronization. This is a topic too broad to cover easily in an answer here. But for a quick and dirty answer, check out synchronized methods. If you just make the method that handles this list access synchronized, then it will be safe. Of course, depending on your needs, locking the list access might take away any performance gain from your threads.
3) It doesn't necessarily have to, but it generally does. "TCP socket" is even more likely than "UDP socket", but both work. If you want a dedicated and reliable connection for an entire, prolonged transaction, you should probably use TCP. TCP makes guarantees that data was received and that it was received in a certain order.
I have been reading through the Java tutorial on RMI. I like the approach that is outlined here for implementing a remote interface:
http://download.oracle.com/javase/tutorial/rmi/implementing.html
What I would like to know are 2 things:
1) With regard to the executeTask method outlined in the aforementioned link, how would this design allow Remote Objects (tasks) access some sort of global state if the ComputeEngine is just calling the execute method of a Task?
2) Would this design be suitable for a multi-threaded environment?
Thanks indeed.
Ad. 1: Please note that remote client does not know anything about ComputeEngine class, only the Compute interface. Also, the server implementation might change completely, but if the interface does not change, client shouldn't notice. If you want to pass some context to the task coming from remote client, do it on interface layer:
public class ComputeEngine implements Compute {
private GlobalContext globalContext = //...
public <T> T executeTask(Task<T> t) {
return t.execute(globalContext);
}
This way each task has access to the globalContext and knows exactly what to expect from globalContext (what are the server capabilities, the context). GlobalContext would be a JavaBean or more likely some service interface.
On the client side it might look like this
Compute compute = //obtain RMI client stub somehow
compute.executeTask(new Task<String>() {
public String execute(GlobalContext globalContext) {
//Note that this code is executed on the server and
//getFoo() is implemented on the server side. We only know its interface
globalContext.getFoo();
//...
}
}
Ad. 2: It will work with multiple clients calling the service concurrently. However it is up to you to implement the server in thread-safe manner. The example from tutorial you mentioned in thread-safe, but my code using GlobalContext might not be. Please notice that several clients will use the same instance of globalContext concurrently, which might, but does not have to cause some issues. That's probably the most interesting part.
And finally remember that receiving unknown Task from remote client and running it on server is very impressive, but not quite safe.