Tim Driven Development | Test until the fear goes away
Tim Driven Development | Test until the fear goes away
Junilu Lacar wrote:I have to echo Tim's sentiments here about your approach. It has elements that indicate NIH (not invented here) syndrome and PHB (pointy-haired boss) syndrome. Both of these are anchored in naïveté at best. We're not saying you're stupid but there's also an inherent guilt by association bias that's involved.
s ravi chandran wrote:On an entirely different note; how about using a simple blocking queue for this task? I can add and remove element and it will block if there are not elements to process.
s ravi chandran wrote:
1. All the messages need to be delivered.
2. Maximum throughput for read and write
3. Communication will always happens within same jvm.
s ravi chandran wrote:
I will stop doing random experiments and check out the AMQP.
About the requirement:
This needs to be reliable, but I was not given any specific instruction like persisting the data which can be recovered later. So, I am considering that the reliability of message delivery stops at the point where the system crashes.
s ravi chandran wrote:
I like the way JMS works, just have producer consumer implementations and you are done. But it does involve serialization- deserialization each time.
Tim Driven Development | Test until the fear goes away
Tim Driven Development | Test until the fear goes away
Does the queue have a fixed capacity to hold messages? I wish to keep it unbounded. Would it not be optimal that way?
Does the queue need to block when it's full/empty? Yes.
Is the queue thread-safe? Basic version wont be thread safe.
Does the queue pull or push? This queue will be push based model
If the queue is push-based, does it have a fixed capacity to hold consumers? Yes.
If the queue supports multiple consumers, when is a message removed from the queue? Not applicable in current design
s ravi chandran wrote:I wish to keep it unbounded. Would it not be optimal that way?
Basic version wont be thread safe.
When there is no element left to be processed by the consumer, the consumer will block. When producer adds more data, consumer will start processing again.
Now I need a message/event handler which should be used by the consumer for processing. how do I link this handler with consumer? one way would be to have the handler implementation implicitly passed to the consumer.
Does something like [...] look better?
Stephan van Hulst wrote:
Why have a custom class for consumers anyway? Java already provides a Consumer interface. In the simplest form, you can just pass a lambda expression or a method handle to an addConsumer() method on the queue.
How are you going to guarantee reliable message passing if there is one thread for the producer, and one thread for the queue?
This means the thread that notifies consumers has to wait inside the queue, until it's notified of a new element by the producer thread.
Why have a custom class for consumers anyway? Java already provides a Consumer interface. In the simplest form, you can just pass a lambda expression or a method handle to an addConsumer() method on the queue.
s ravi chandran wrote:If I have a basic queue where I add to the end and remove from the start, will it have conflict?
So, I implement this consumer interface. How will producer and consumer know about each other? as they both share common queue, will using a lock condition be the right way to communicate between them?
Stephan van Hulst wrote:
s ravi chandran wrote:If I have a basic queue where I add to the end and remove from the start, will it have conflict?
Yes it will, if you're using separate threads for the producer and the pushing mechanism. You can implement a concurrent, bounded, blocking queue by writing a circular buffer with locks.
So, I implement this consumer interface. How will producer and consumer know about each other? as they both share common queue, will using a lock condition be the right way to communicate between them?
The producer and consumer shouldn't know about each other. The producer just adds messages to the queue, and the queue's pushing mechanism notifies the registered consumer when a message is available.
Stephan van Hulst wrote:That's a bit of a roundabout way of doing things. It should actually be like this:
Don't get me started about those stupid light bulbs. |