Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sample Broker seems to get lost when it gets out of sync #492

Closed
jecollins opened this issue Feb 16, 2012 · 3 comments
Closed

Sample Broker seems to get lost when it gets out of sync #492

jecollins opened this issue Feb 16, 2012 · 3 comments

Comments

@jecollins
Copy link
Member

I ran a sim last night with both server and sample broker on my desktop machine. Around timeslot 414, the server took nearly 5 seconds, and the sample broker's orders were still arriving when the market clearing began. Some of the orders ended up in the next market clearing, and the broker appears to have choked on one or more of the resulting market transactions. Eventually the server choked on a NPE:

Exception in thread "Thread-10" java.lang.NullPointerException
    at org.powertac.server.BrokerProxyService.localSendMessage(BrokerProxyService.java:94)
    at org.powertac.server.BrokerProxyService.broadcastMessage(BrokerProxyService.java:149)
    at org.powertac.server.WeatherService.activate(WeatherService.java:152)
    at org.powertac.server.CompetitionControlService.step(CompetitionControlService.java:557)
@jecollins
Copy link
Member Author

Actually, the backtrace shown above is unrelated to the sample broker issue, and it seems that the sample broker is not causing the sim to crash. What we see in the backtrace is apparently what happens when the sim happens to end while the weather service is trying to retrieve data, which happens once every 24 timeslots. Presumably this error would go away with a solution to #348.

@jecollins
Copy link
Member Author

I believe there is a problem with the threading model in the sample broker. The broker starts up, sets up the JMS channels, logs in, then waits for a signal that the sim is complete. All the actual processing happens in the threads managed by the jms infrastructure. Depending on how the JMS system manages its threads, this could easily lead to significant lag between the server's clock and the broker's clock, and therefore to broker messages being received too late in the server. I suggest we do all the processing other than receiving messages in the original thread, and cut off processing when the timeslot advances (when we receive the timeslot-update message).

@jecollins
Copy link
Member Author

Added new TimeslotComplete message as last in timeslot, check for correct timeslot during processing. Change threading model to move broker processing out of jms threads, handle all message types to avoid error messages.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant