Question

I am using protobuf for implementing a communication protocol between a Java application and a native application written in C++. The messages are event driven: when an event occurs in the C++ application a protobuf message is conructed and sent.

message MyInterProcessMessage {

   int32 id = 1;

   message EventA { ... }
   message EventB { ... }
   ...
}

In Java I receive on my socket an object of the class: MyInterProcessMessageProto. From this I can get my data very easily since they are encapsulated into each other: myMessage.getEventA().getName();

I am facing two problems:

1. How to delegate the processing of the received messages?

   Because, analysising the whole message and distinguishing the different event types and the actions they imply resulted in a huge and not maintainable method with many if-cases.

2. I would like to find a pattern, where I can preserve the messages and not only apply them, but also undo them, like the Command pattern is used to implement this.

My first approach would be: create different wrapper classes for each event with a specified apply() and undo() method and delegate the job this way.

However I am not sure if this is the right way or whether there are not any better solutions.

---

To clarify my application:

The Java application models a running Java Virtual Machine and holds information, for instance Threads, Monitors, Memory, etc.

Every event changes the current state of the modeled JVM. For instance, a new thread was launched, another thread goes into blocking state, memory was freed etc. In the same meaning the events are modeled: ThreadEvent, MemoryEvent, etc.

This means, the messages have to be processed sequentially. In order to iterate back to previous states of the JVM, I would like to implement this undo functionality.

For undo I already tried. clearAllStates, apply Events until Event #i.

Unfortunately with 20.000+ events this is total inefficient.

Answer 1

To provide a tailored answer it would be good to know what you’re doing with received messages, if they can be processed concurrently or not, and how an undo impacts the processing of messages received after and undo‘ed message.

However, here’s a generic suggestion: A typical approach is to delegate received messages to a queue-like handler class, which usually runs in an own thread (to let the message receiver get ready for the next incoming message as soon as possible) and sequentially processes received messages. You could use a stack-like class to keep track of processed messages for the sake of the undo feature. You could also use specific queues and stacks for different event types.

Basically this resembles the thread pool pattern.