Statistics using ExecutionAttributes are inaccessible?

Hi,

I'm using m4, and trying to store statistics in a context aware ItemWriter, using context.setAttribute.

When I try to fetch the statistics i get nothing back.

Using a debugger I noticed that SimpleStepContext gets registered using itself as the key. SimpleStepContext gets its hashCode implementation from SynchronizedAttributeAccessor which delegates to AttributeAccessorSupport and eventually to LinkedHashMap. The hashCode calculated by LinkedHashMap is based on the items the map contains, and will therefore change whenever items are added.

This means that if you add items to the map (which setAttribute does) after it has been registered, you will never be able to take it out (the map will look in the wrong bucket).

Am I doing this wrong or is this a bug?

I noticed if I implement the ItemStream interface in my custom ItemWriter, I can return statistics in the getExecutionAttributes() method.
I'm using StaxEventItemReader as the reader, but its getExecutionAttributes() method doesn't get called. I don't get this... :confused:

To answer the first question, context.setAttribute doesn't actually put the attribute in ExecutionAttributes, but rather to the stepContext itself. I realize this is a little bit confusing, and it has been updated in M5. For example, ExecutionAttributes is now called ExecutionContext, among other changes.

The reason why your xml item reader isn't being called is because it's not step scoped. This requires you to put scope="step" along with making sure it's an aop proxy. We've made this easier in M5, but it's still a requirement in M4.

Thanks for the quick response.

Actually I have both my reader and writer in step scope (and with aop:scoped-proxy). I can't figure out why the writer gets called and the reader isn't.

Progress...

If the writer doesn't get called (the reader returns null on the first time it is called), I do get the statistics from the reader. Looks like the registrations overwrite each other.

I know retrieving the ExecutionAttributes is a bit flaky in M4, which is why I completely rewrote it for M5. However, I do know that our various tests for restart all worked in M4, which would require ItemStream reading to work on the reader. Since M5 should be officially release any day now, it might be better to switch to it than try and debug the issue with m4. If it's not too difficult you could even try switching to trunk quickly to see if it fixes your issues.

I've updated to m5 and can now get the statistics. Thanks for your help.