receiving forecast notification results in failure

[David Dauer]

SUMMARY

I'm trying to create a competition and get the demo agent to receive notifications... this is how:

STEPS TO REPRODUCE

1. On a clean installation of tacenergy-0.6, I created a new competition with "number of participants" set to 1.
2. With a clean build of tacenergydemo-0.5, I click on "Send Ready Notification to server." and can confirm that the server recognizes the tacenergy1 user as ready.
3. A few seconds later, the demo agent fails with "2010-05-03 22:41:07,799 [jmsForecastContainer-1] ERROR tacdemo.JmsNotificationService - Failed to save received forecastNotification as local Forecast: org.springframework.validation.BeanPropertyBindingResult: 1 errors
Field error in object 'edu.kit.iism.tacdemo.Forecast' on field 'product': rejected value [null]; codes [edu.kit.iism.tacdemo.Forecast.product.nullable.error.edu.kit.iism.tacdemo.Forecast.product,edu.kit.iism.tacdemo.Forecast.product.nullable.error.product,edu.kit.iism.tacdemo.Forecast.product.nullable.error.edu.kit.iism.tacdemo.Product,edu.kit.iism.tacdemo.Forecast.product.nullable.error,forecast.product.nullable.error.edu.kit.iism.tacdemo.Forecast.product,forecast.product.nullable.error.product,forecast.product.nullable.error.edu.kit.iism.tacdemo.Product,forecast.product.nullable.error,edu.kit.iism.tacdemo.Forecast.product.nullable.edu.kit.iism.tacdemo.Forecast.product,edu.kit.iism.tacdemo.Forecast.product.nullable.product,edu.kit.iism.tacdemo.Forecast.product.nullable.edu.kit.iism.tacdemo.Product,edu.kit.iism.tacdemo.Forecast.product.nullable,forecast.product.nullable.edu.kit.iism.tacdemo.Forecast.product,forecast.product.nullable.product,forecast.product.nullable.edu.kit.iism.tacdemo.Product,forecast.product.nullable,nullable.edu.kit.iism.tacdemo.Forecast.product,nullable.product,nullable.edu.kit.iism.tacdemo.Product,nullable]; arguments [product,class edu.kit.iism.tacdemo.Forecast]; default message [Property [{0}] of class [{1}] cannot be null]".

NOTES

reproducible.

[Carsten Block (cblock)]

Hi David!

Yes. Confirmed. The problem is that currently we use a public topic to send out product notifications to all competition participants and private queues for each participant to send out individual demand forecasts. In the above case the forecast message is processed by the client before the the topic message announcing the product.

When the agent then tries to process the forecast message and to create a forecast db object there will be no product instance in the db due to the product notification message coming in late. This results in a failure due to referential integrity in the db being violated.

The solution is likely to completely abandon public topics and to switch communication between client and servers to one queue for each direction and agent. Like this message order can be guaranteed. For Activemq we need to look into the concept of composite destinations to deliver messages to several different queues in parallel.

[David Dauer (ddauer)]

what are the recommended values for the workaround listed in the documentation?

Config.groovy: databinding {
    retryCount = 30 //original value: 5 # times to retry databinding
    retryWait = 10000 //original value: 1000 milliseconds to wait before retrying databinding
  }

does not throw an error but also doesn't log the default "Product received:..." info message. (log levels are default and seem to be correct). so I'm guessing the adjustments still didn't work?

[Carsten Block (cblock)]

The error seems to pertain for the first two forecasts sent out. Afterwards everything seems to work with the default values of retryCount=3 and retryWait = 500.

For 0.6 (server and client) we will completely refactor the JMS communication to work on a single queue per competition participant only. As the error reported here stems from a concurrency issue between several different queues / topics the 0.6 release will conceptually solve the problem.

For the time being: Simply ignore the first two forecast errors. Tthey seem to always occur and there should be no other errors of this type during the rest of a competition. You might want to start trading only on the third product until 0.6 version is released.

[Daniel Schnurr (danielschnurr)]

There is a problem responsible for those errors besides the concurrency issue relating to queues and topics:

One error seems to occur since the forecast horizon is calculated one timeslot ahead of the enabled products. Therefore the client receives a forecastNotification for a product that he will not receive until the next timeshift.

This problem can be simply solved by changing the criteria in line 61 of the ForecastGeneration service from
---------------------
if (forecastHorizon <= competition.timeslotsOpen) {
to
if (forecastHorizon < competition.timeslotsOpen) {
---------------------
I am now checking for possible side effects. Fix will be released with next version.

The second error seems to occur because of the deactivateTimeslotsAhead property: if it is set to 1 as in default mode,
the client does not receive a ProductNotification for the first product but still receives a ForecastNotification.
Fix will be released as well in the next version.

Nevertheless both errors do not effect the implementation of your agent beacuse the forecastNotification that now results in an error will not be sent at all in the correct version.

[Carsten Block (cblock)]

Thanks much, Daniel!

Am 07.05.10 17:43 schrieb "Daniel Schnurr" unter <email address hidden>:

> There is a problem responsible for those errors besides the concurrency
> issue relating to queues and topics:
>
> One error seems to occur since the forecast horizon is calculated one
> timeslot ahead of the enabled products. Therefore the client receives a
> forecastNotification for a product that he will not receive until the
> next timeshift.
>
> This problem can be simply solved by changing the criteria in line 61 of the
> ForecastGeneration service from
> ---------------------
> if (forecastHorizon <= competition.timeslotsOpen) {
> to
> if (forecastHorizon < competition.timeslotsOpen) {
> ---------------------
> I am now checking for possible side effects. Fix will be released with next
> version.
>
>
> The second error seems to occur because of the deactivateTimeslotsAhead
> property: if it is set to 1 as in default mode,
> the client does not receive a ProductNotification for the first product but
> still receives a ForecastNotification.
> Fix will be released as well in the next version.
>
> Nevertheless both errors do not effect the implementation of your agent
> beacuse the forecastNotification that now results in an error will not
> be sent at all in the correct version.