Sharing thread between processes

Question

I suppose this is not possible. But I am looking at best way to separate different layers of my service yet be able to access layers quickly or without overhead of IPC/RMI.

The main programming language I am using is java, but can use C++ if required.

What we have right now is a server that host database and access control. And we use RMI for consumers to request data. This slow and doesn't scale very well.

We need performance and scalability which we dont have at the moment.

What we are thinking of is using a layered architecture with database at base, access control ontop of it along with a notification bus to notify clients of changes in database. The main problem is the overhead of communication that we want to avoid/or minimize.

Is there any magic thread that can run in two context (switch context) and share information that way. I know the short answer would be no, but what are the options?

Update

• We are currently using Java RMI.

Our base layer will provide an API that can be used to create plugins that will run on top. So its not a fixed collectors/consumer we have. We can have 5-6 collectors running and same amount of consumers.

We can have upto 1000 consumers.

Answer 1

It is not possible in general to share thread between two processes due to OS design. The problem of sharing data between two or more processes is usually solved by sharing files, sharing database or sharing messages (which in turn can be synchronous or asynchronous), having processes communicate via pipes, say in Linux, or even sharing memory. You scenario description is not very precise, you need to describe all processes and how information is supposed to flow, what triggers information flow, etc.

Most likely you need high performance messaging library, https://github.com/real-logic/Aeron/ is one. But to get precise answer you would need to describe better what overhead exactly you want to minimize.

Answer 2

My first suggestion is that you should buy a book (or find an online tutorial) on building scalable applications, because you seem to be pretty lost.

Sharing a thread between processes doesn't make sense at any level - it is meaningless, but you can share the data that the thread accesses, which is probably what you want.

The fastest method will be C based IPC (e.g., shared memory, semasphores, etc: Shmget). You say you want to avoid the overhead of IPC, but really, it isn't going to get any faster than that.

But why do you want multiple processes? If you are worried about the overhead of communicating between processes, just have your threads in one process? There is no reason your different layers have to be in different processes.

But anyway, I am not convinced that your original statement that RMI is slow and doesn't scale is completely correct. If it is not scaling, you are probably not using the right framework. Maybe you have an issue that you only have one RMI end point on the server. Have you considered an J2EE system with stateless session beans?

Without knowing about your requirements, it is hard to say.

Answer 3

If your goal is to notify users, you should consider publish/subscribe messaging (pub/sub). There are many middleware vendors out there that provide this architecture though most are expensive in production scenarios. For open source, check out http://redis.io/topics/pubsub. (No affiliation.)