I am working a much more complex version of this (with vehicle moving in both X and Y directions)
I made this example to get ideas on better ways to accomplish this.
- I have a vehicle moving in the X direction at a speed (24.5872 mps)
- I am simulating this by incrementing the X value every 100 ms using an executor (To keep its X position more accurate and real time)
- After each second, I send a message to another process with the xMin and xMax values of the line I just covered
- The other process will respond with a JMS message (usually instantly) telling me to stop if there was an “Pothole” in the previous X area (Message callback msg to a linkedblockingqueue).
The problem I have is with the “usually instantly” part. If I do not get a response quick enough, I think it will throw off the whole timing of my algorithm. What is a better way to handle this situation?
Here is some basic code of what I am trying to do:
public class Mover implements MessageHandler {
private static final long CAR_UPDATE_RATE_IN_MS = 100;
private static double currX = 0;
private static double CONSTANT_SPEED_IN_MPS = 24.5872; // 55 mph
private static double increment = CONSTANT_SPEED_IN_MPS / (1000 / CAR_UPDATE_RATE_IN_MS);
static LinkedBlockingQueue<BaseMessage> messageQueue = new LinkedBlockingQueue<BaseMessage>(); // ms
private static int incrementor = 0;
public static void main(String[] args) {
startMoverExecutor();
}
private static void startMoverExecutor() {
ScheduledExecutorService mover = Executors.newSingleThreadScheduledExecutor();
mover.scheduleAtFixedRate((new Runnable() {
@Override
public void run() {
currX = incrementor * increment;
if (incrementor % (1000 / CAR_UPDATE_RATE_IN_MS) == 0) {
System.out.println(currX);
sendMessage(currX - CONSTANT_SPEED_IN_MPS, currX);
// do something
try {
messageQueue.poll(1000, TimeUnit.MILLISECONDS);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
incrementor++;
}
}), 0, CAR_UPDATE_RATE_IN_MS, TimeUnit.MILLISECONDS);
}
@Override
public void handleMessage(BaseMessage msg) {
messageQueue.add(msg);
}
protected static void sendMessage(double firstX, double secondX) {
// sendMessage here
}
}
I am proposing changes to your algorithm above as shown in steps below.
JMS Call to other process
1a. Start with sending the current position of vehical.
1b. The other process will respond with a JMS message containing list of all the “Pot holes positions” in the visible area of your vehical’s position. Keep this list of “visible pot holes positions” at client side for use in steps below.
1c. We define visible area as vehical’s neighbouring area such that even with (1-second-delay + network-lag) of calling other process with JMS, movement of vehical should not cross this area.
1d. After each second, repeat steps 1a and 1b and replace list of pot holes positions at client side relative to current position of your vehical.
.
Vehical movement observer
2a. Implement an Observer pattern which can receive notifications of vehical movements.
2b. Each time event is generated, observer will make a check if vehical’s position matches with one of the entry in list of visible pot holes acquired in step 1b.
2c. If match found, bingo! You got to stop the vehical.
.
Vehical movement
3a. Register step-2a observer to observe vehical’s movements
3b. Wait until you have got atleast first list of visible pot holes from step 1b.
3c. Start moving the vehical by incrementing the X value every 100 ms. Each time it moves, it should notify the step-2a observer.
.
Legends for below diagram: