I would like to know the approaches to get synchronization on Camel Processor.
The only related thing that I found at docs:
Note that there is no concurrency or locking issue when using
ActiveMQ, JMS or SEDA by design; they are designed for highly
concurrent use. However there are possible concurrency issues in the
Processor of the messages i.e. what the processor does with the
message?
So if I want to get lock on org.apache.camel.Processor.process(Exchange) , i.e. I would like other threads wait for process method finishing while it is busy. Is that possible?
UPDATE: Actually I tried to make synchronized (lock) inside of process method - that works on JVM side. But my Processor is part of transaction-ed route and that is a problem - all changes to Persistence Layer become visible only after exiting Processor (or even maybe route). So I thought there are some Camel-like solutions for this problem.
The business logic you implement inside a Camel processor must be thread-safe, as multiple threads would reuse the same instance during routing messages in Camel.
If you want to use prototype scoped (eg creating a new instance of the processor for each message) then you can use the bean component, and set cache=false, and if you use spring, then declare the bean as prototype
<bean id="myBean" class="com.foo.MyBean" scope="prototype"/>
And then call this bean in a route
.to("bean:myBean?cache=false")
Though very often people use singleton instances.
If you want any kind of locking you can define the method as synchronized and let the JVM lock it for you.
public synchronized void process(Exchange exchange) throws Exception {
...
}
Related
I'm working with a boost::statechart::state_machine and I experienced a crash in the machine. Upon investigation of the core I realized that it happened because multiple threads processed an event around the same time, one of which called terminate and the other of which crashed because it tried to use a terminated object.
I therefore need to know what my options are for making my state machine thread-safe. In looking at the boost's statechard documentation, it explicitly says that statechart::state_machine is not thread-safe and indicates that thread-safety can be accomplished by aynchronous_state_machine. But asynchronous_state_machine looks like it solves more problems than just thread safety and converting from state_machine to asynchronous_state_machine looks non-trivial. Can I achieve a thread-safe implementation by simply locking around my calls to process_event?
As an alternative to mutex semaphores or locks, you might consider a monitor.
The state machine can possibly be just as you have it now.
There are several kinds I know of, and I have (not so recently) used a Hoare Monitor for a state machine of my own design (not boost).
From wiki-pedia: "In concurrent programming, a monitor is a synchronization construct that allows threads to have both mutual exclusion and the ability to wait (block) for a certain condition to become true. "
My implementation of a Hoare Monitor transformed any event (input to my state machine) into an IPC message to the monitor thread. Only the monitor thread modifies the state machine. This machine (and all its states) are private data to the class containing the monitor thread and its methods.
Some updates must be synchronous, that is, a requesting thread suspends until it receives an IPC response. Some updates can be asynchronous, so the requesting thread need not wait. While processing one thread request, the monitor ignores the other thread requests, their requests simply queue until the monitor can get to them.
Since only 1 thread is allowed to directly modify the (private data attribute) state machine, no other mutex schemes are needed.
That effort was for a telecommunications device, and the events were mostly from human action, there for not time critical.
The state machine can possibly be just as you have it now. You only need to implement the monitor thread, decide on an IPC (or maybe inter-thread-comm) and ensure that only the one thread will have access to the state machine.
When working with #Singleton type of EJB having container managed concurrency enabled and there is a pending write lock to #Lock(LockType.WRITE) annotated method, will possible callers of #Lock(LockType.READ) methods be queued in order of invocations?
In other words, if multiple invocations to read locked methods are pending a write locked invoker, will those read locked method callers get their calls through in order in which the invocations arrived (assuming no timeouts occur)?
I've been testing this and have gotten somewhat conflicting results.
The EJB specification makes no guarantees about singleton session bean lock fairness, so you shouldn't make any assumptions. If your application server makes some guarantee, I guess you could rely on that, but you're probably better off using #ConcurrencyManagement(BEAN) and using your own lock that ensures fairness.
I'm wondering how asynchronous EJB methods are scheduled onto the underlying plateform (SMP/NUMA plateform for example) ?
Can anyone describe the scheduling middleware (I'm not familiar with EJB).
EJB as a spec doesn't say how this should be exactly implemented, giving implementations the free hand to choose how to do this.
That said, the implementations I've seen simply use a thread pool. It functions pretty much like an executor service does in Java SE. A call to an #Asynchronous methods results in a task being put in a queue, which is serviced by said thread pool.
SMP/NUMA properties are not directly influenced by EJB, but depend on how the underlying operating system handles threads within a single process.
I am working on a RPC framework, I want to use a multi io_service design to decouple the io_objects that perform the IO (front-end) from the the threads that perform the RPC work (the back-end).
The front-end should be single threaded and the back-end should have a thread pool. I was considering a design to get the front-end and back-end to synchronise using a condition variables. However, it seems boost::thread and boost::asio do not comingle --i.e., it seems condition variable async_wait support is not available. I have a question open on this matter here.
It occured to me that io_service::post() might be used to synchronise the two io_service objects. I have attached a diagram below, I just want to know if I understand the post mechanism correctly, and weather this is a sensible implementation.
I assume that you use "a single io_service and a thread pool calling io_service::run()"
Also I assume that your frond-end is single-threaded just to avoid a race condition writing from multiple threads to the same socket.
The same goal can be achieved using io_service::strand (tutorial).Your front-end can be MT synchronized by io_service::strand. All posts from back-end to front-end (and handlers from front-end to front-end like handle_connect etc.) should be wrapped by strand, something like this:
back-end -> front-end:
io_service.post(front_end.strand.wrap(
boost::bind(&Front_end::send_response, front_end_ptr)));
or front-end -> front-end:
socket.async_connect(endpoint, strand.wrap(
boost::bind(&Front_end::handle_connect, shared_from_this(),
boost::asio::placeholders::error)));
And all posts from front-end to back-end shouldn't be wrapped by strand.
If you back-end is a thread pool calling any of the io_service::run(), io_service::run_one(), io_service::poll(), io_service::poll_one() functions and your handler(s) require access to shared resources then you still have to take care to lock those shared resources somehow in the handler's themselves.
Given the limited amount of information posted in the question, I would assume this would work fine given the caveat above.
However, when posting there is some measurable overhead for setting up the necessary completion ports and waiting -- overhead you could avoid using a different implementation of your back end "queue".
Without knowing the exact details of what you need to accomplish, I would suggest that you look into thread building blocks for pipelines or perhaps more simply for a concurrent queue.
I'm refactoring a project that I did not design. It is written in C/C++ for linux. The project has a major client component that looks like this:
Client -> Output Queuing Library (OQL) -> Controller
Client
Messy semi-complex code, poorly designed (hodgepodge of OOP approximations using singletons/namespaces, just weird in many places - but it works)
Custom protocol implementation (not my protocol, cannot modify)
Shared Library
Multi-threaded
Multiple threads call the OQL api, ie multiple threads output
Accepts commands from controller via API
Produces massive unsequenced output which is affected but not necessarily directly (and definitely not 1:1) by the controller input)
Output Queuing Library (OQL)
Simple clean code, not really designed for it's current workload (was never meant to queue, was actually originally just writing to stdout and then a message queue was shoe-horned in)
Shared Library
Single-threaded
Exposes API which accepts many types of data from the client and builds textual representations of this data
Inserts data into a sys V message queue
Controller
Executable
Single-threaded
Elegant, fault tolerant C++ which makes extensive use of boost
Written from scratch by me, the only part of the project I've been allowed to completely "fix" so to speak
Interacts with client library via API to initiate connection to server
Saves data produced by Client and read from OQL into database in another layer
So the problem essentially boils down to this, the controller is single threaded and calls many API functions in the client library. Scenarios resulting from Controller calling Client API.
Normal (98%+)
Controller calls client API function
Client API function does magic internally
API function returns true
Client receives data as a result of magic in step 2, in another thread of execution and calls OQL put function from a secondary thread
OQL writes data to message queue, queue either blocks or does not block but neither matter since the controller's main thread of execution is running and processing data.
Success!
Problem Scenario
Controller calls client API function
Client API function immediately produces result and BEFORE returning calls OQL put function from the main thread of execution in the Controller
OQL writes data to the message queue and one of the following happens:
Message queue is not full, does not block, everything returns and the controller processes the new data in the message queue and life moves on happily
Problem Scenario Message queue IS full and DOES block
Now what I'm sure you can see is in the problem scenario, which is rare, the main thread of execution is blocking on a full message queue and also no data is being processed off of the other end of the queue since the controller is single threaded...
So yes it's a bit of a mess, and no I'm not happy with the design but I've gotta figure out the best way to solve this without rewriting all of these interactions.
I'm trying to decide between:
Digging into the client, synchronizing all of the threads to a single I/O thread that interacts with OQL
I have basically zero faith that someone after me will not come in and break this down the road, introduce massive bugs and not be able to understand why
Introducing a writer thread into OQL
Takes a simple class and complicates it significantly
Introduces funny problems
Doesn't the queue need a queue at that point? Since data has to get transported to the writer thread
Really just typing up this question was probably the best thing I could have done, since my thoughts are much more organized now...but does anyone have any input to offer here? Is there some design pattern I'm not seeing which would not require massive refactoring, and are my concerns overblown on either of these? I'm not even sure if it's possible for anyone to provide meaningful advice here without knowing all angles of the problem, but I appreciate any insight you guys can offer.
Change client to return an error when the Q is full so the controller can make an intelligent decision about how to continue.
You could change the Controller to use a second thread to do the reading from the message queue (and just post the data to a much larger buffer, internal to the Controller, to be read by the main Controller thread).