I am writing an application similar to a chat server-client pair.
I am planning on having a central Object which will hold new messages received from clients until they are dealt with by the main thread.
My application is multi-threaded. Each client will be on its own thread, so multiple threads will be adding messages to this central Object.
The main thread will check this Object for messages, remove the "oldest" and deal with it appropriately. Preferably I would like the messages to be handled in the same order they were added (FIFO).
What type of Object is most appropriate to hold the new messages? I looked into Vectors and ArrayLists, but I am confused about the synchronization aspect. I never worked with synchronization or threads before.
Thank you
ConcurrentLinkedQueue sounds likely.
More info here: How to use ConcurrentLinkedQueue?
Javadoc here: http://download-llnw.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/ConcurrentLinkedQueue.html
If this is to become more than a little toy project, you should look into JMS which solves all of the little problems that you're not aware of, yet.
A good implementation of JMS is Apache ActiveMQ (not related to IBM's MQSeries).
You may also consider jgroups for this project.
JGroups is an open source reliable group communication toolkit. Its reliable and simple to use. Here is a basic chat example in the tutorial of same.
While not a direct answer (As #Alison provided a decent enough of one provided you don't need to persist messages) always have a look at the java.util.concurrent package whenever you need data structure classes or utility classes to help with multi-threaded coded: http://download-llnw.oracle.com/javase/6/docs/api/java/util/concurrent/package-summary.html
Related
I have the following situation:
I have 2 JVM processes (really 2 java processes running separately, not 2 threads) running on a local machine. Let's call them ProcessA an ProcessB.
I want them to communicate (exchange data) with one another (e.g. ProcessA sends a message to ProcessB to do something).
Now, I work around this issue by writing a temporary file and these process periodically scan this file to get message. I think this solution is not so good.
What would be a better alternative to achieve what I want?
Multiple options for IPC:
Socket-Based (Bare-Bones) Networking
not necessarily hard, but:
might be verbose for not much,
might offer more surface for bugs, as you write more code.
you could rely on existing frameworks, like Netty
RMI
Technically, that's also network communication, but that's transparent for you.
Fully-fledged Message Passing Architectures
usually built on either RMI or network communications as well, but with support for complicated conversations and workflows
might be too heavy-weight for something simple
frameworks like ActiveMQ or JBoss Messaging
Java Management Extensions (JMX)
more meant for JVM management and monitoring, but could help to implement what you want if you mostly want to have one process query another for data, or send it some request for an action, if they aren't too complex
also works over RMI (amongst other possible protocols)
not so simple to wrap your head around at first, but actually rather simple to use
File-sharing / File-locking
that's what you're doing right now
it's doable, but comes with a lot of problems to handle
Signals
You can simply send signals to your other project
However, it's fairly limited and requires you to implement a translation layer (it is doable, though, but a rather crazy idea to toy with than anything serious.
Without more details, a bare-bone network-based IPC approach seems the best, as it's the:
most extensible (in terms of adding new features and workflows to your
most lightweight (in terms of memory footprint for your app)
most simple (in terms of design)
most educative (in terms of learning how to implement IPC). (as you mentioned "socket is hard" in a comment, and it really is not and should be something you work on)
That being said, based on your example (simply requesting the other process to do an action), JMX could also be good enough for you.
I've added a library on github called Mappedbus (http://github.com/caplogic/mappedbus) which enable two (or many more) Java processes/JVMs to communicate by exchanging messages. The library uses a memory mapped file and makes use of fetch-and-add and volatile read/writes to synchronize the different readers and writers. I've measured the throughput between two processes using this library to 40 million messages/s with an average latency of 25 ns for reading/writing a single message.
What you are looking for is inter-process communication. Java provides a simple IPC framework in the form of Java RMI API. There are several other mechanisms for inter-process communication such as pipes, sockets, message queues (these are all concepts, obviously, so there are frameworks that implement these).
I think in your case Java RMI or a simple custom socket implementation should suffice.
Sockets with DataInput(Output)Stream, to send java objects back and forth. This is easier than using disk file, and much easier than Netty.
I tend to use jGroup to form local clusters between processes. It works for nodes (aka processes) on the same machine, within the same JVM or even across different servers.
Once you understand the basics it is easy working with it and having the options to actually run two or more processes in the same JVM makes it easy to test those processes easily.
The overhead and latency is minimal if both are on the same machine (usually only a TCP rountrip of about >100ns per action).
socket may be a better choice, I think.
Back in 2004 I implement code which do the job with sockets. Until then, many times I search for a better solution, because socket approach triggers firewall and my clients worry. There is no better solution until now. Client must serialize your data, send and server must receive and unserialize.
It is easy.
From the docs
It is not a general-purpose publish-subscribe system, nor is it intended for interprocess communication
What do they mean by saying it's not a general-purpose publish-subscribe system?
As far as I understand this is within a JVM only, publish/subscribe is usually between processes residing in potentially different places: like one JVM talking to another, suppose one Spring application publishing events that are to be consumed by another Spring application, residing in entirely different places.
It's better explained in the bottom of the EventBusExplained page:
Why can't I do <magic thing> with EventBus?
EventBus is designed to
deal with a large class of use cases really, really well. We prefer
hitting the nail on the head for most use cases to doing decently on
all use cases.
Additionally, making EventBus extensible -- and making it useful and
productive to extend, while still allowing ourselves to make additions
to the core EventBus API that don't conflict with any of your
extensions -- is an extremely difficult problem.
If you really, really need magic thing X, that EventBus can't
currently provide, you should file an issue, and then design your own
alternative.
(Emphasis mine.)
Compare EventBus to Kafka for example -- the latter is much more extensible but also more complex.
In Stomp, how can I browse all queues or/and topics available? Is it possible at all?
The key here is to get the result and the language is not important, it can be either python, ruby or java because as I've found out it's easier to do this particular task using them because of the existing libraries. Python seems to have only one most popular library, though.
Well, the simple answer is that you can't. That's not part of the Stomp protocol.
The complex answer, as always, is "it depends". It's entirely possible that whatever is providing your stomp service will have something that you can use. (In RabbitMQ, for example, you can log in to the web interface and look at the current queue names).
However the whole point of Stomp (and to a certain extent in all messaging) is that there aren't really "desintations", just queues which can be read by one or more clients. And the queues are transient; you might find the information deprecates pretty quickly...
I'm used to C++/Qt's concept of signals (emit/listen) and now I'm doing a project in Java which requires some sort of data sending/receiving mechanism.
My needs are:
Emit an event (with some data) and let all threads listen/catch it.
Obviously, given the previous requirement, being able to listen/catch signals with attached data.
Is this possible in Java, and how? (I'll appreciate a small compilable example/link)
Java by default doesn't have a simple event handling mechanism such as .Net's events or Qt's Signals and Slots. It does have the notion of Listeners in various java GUI frameworks but I don't think that's what you're looking for.
You should consider a pub-sub library like Google Guava's EventBus framework.
If you don't want to use a third party lib then I suggest you start looking into using one of the sub-classes of BlockingQueue. See the FileCrawler example from page 62 of Java Concurrency in Practice to see how to use a BlockingQueue to send events/data to worker threads.
If you're looking for a more complicated solution for message/event notifications across the process boundary or the local machine boundary then you may want to look into:
RabbitMq
Redis
JMS
not sure if this will match your exact query but have you tried CountDownLatch or CyclicBarrier?
http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/CountDownLatch.html
http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/CyclicBarrier.html
I am looking to exchange messages between Java classes which are running as part of different Java processes (or JVMs). For example: a Java class which has detected an event will wrap it up as a Java message and send it to an event handling class running inside a different Java process.
What's a simple and well established approach to such messaging? Since the messaging will always be between Java classes, I do not want the overhead of XML SOAP or the complexity of Corba.
Thanks
Neel
The standard solution would be JMS. But it seems its very heavy weight for your needs. I would suggest to write a small TCP layer using MINA or something and build a custom solution over it.
You might want to look at Spring-Integration. It has options for both external and internal messaging. You can use JMS, TCP packages, all kinds of stuff.
If you don't need the asynchronous aspect, simple RMI will do.
One option is Jini, now referred to as Apache River.
Jini will help with discovery and serialization. It allows you to call a method in one class from another class running in a different JVM.
Jini is fairly elegant. It's easy to specify which methods are exposed to remote callers. Exceptions from the called method are communicated as exceptions to the caller. Discovery supports painless redundancy.