java real time design rtsj

Question

I am thinking how to build a real-time system using java without Sun Real-time System API.

Say, a boss generates an event at 11:00 am, he has to get feedback at 11:10 am. If no any feedback, he will resend his event.

The staff gets his boss's event at 11:01 am, he has to leave 1 minutes for sending his result back to his boss. So actually he has 8 minutes to do his job. At 11:09 am, he has to send a feedback no matter he finished it or not.

This is a real-time system, isn't it ?

In this case, how to design our system using java ? This is a producer-consumer pattern. In the consumer side, use which object (blockingqueue, delayqueue ...) to meet this requirement ?

Any weblink, open source will be welcome.

Thank.

Answer 1

The system you described can be solved with JMS.

Use a pub-sub JMS queue to assign the work. The "boss" is the publisher. Each member of the staff is a "subscriber".

The "boss" will need to store each message it publishes in a "check back" area (perhaps a list) and set a timer for 10 minutes. When it gets a response to a message, it will clear the timer and remove the message from the "check back" area.

Answer 2

You cannot do real-time programming in the real computer engineering sense in Java. You are at the mercy of a thread scheduler and an operating system with totally unknown underlying properties. If the OS felt like waiting until 11:20 until it got back around to giving the JVM some CPU time, that's its business.

If you mean "realtime" in the Microsofty way as in "Things respond really really fast and we're careful never to block the main UI thread" that doesn't have a well defined technical meaning. It just means "architecture user facing code to give the appearance they don't have to wait on the computer."

--edit in response to comment.

If by 11:08 you mean 'between 11:07:59 and 11:08:01' then regular java can generally do that for you on a modern platform with careful programming. What it can't deliver is a situation where the event happening at 11:08:01 is considered a platform defect, it just doesn't make that guarantee.

When we say 'real time' and what the RTS API is for, is a situation more like "The bonding head must be at these coordinates at exactly this millisecond, if it's more than half a millisecond late, the part will be defective, and if it's more than 2 milliseconds early, a $300,000 servo table is going to crash into its bearings and cause a $10,000,000 assembly line outage."