EntryProcessor invokeAll returning empty ConverterMap{}

Question

Hi All,
I am trying to write a custom entryprocessor and whatever I return from the invokeAll method in the entryprocessor, I am always getting a empty ConverterMap{}. The code for the entryprocessor is as below:
public class CustomEP implements PortableObject, EntryProcessor {
     public CustomEP (){
public Map processAll(Set entries) {
          Map results=new HashMap ();
results.put ("1", "1");
System.out.println("Inside process All method");
          return results;
public Object process(Entry arg0) {
          Map results=new HashMap ();
results.put ("1", "1");
System.out.println("Inside process method");
          return results;
The client code to invoke this entryprocessor is as below:
Map results=cache.invokeAll(AlwaysFilter.INSTANCE, new CustomEP());
The processAll method on the Coherence nodes is invoked but if the print the results on the client side it return empty ConverterMap{}
On the other hand, if I invoke process method of CustomEP as below:
Map results=(Map) cache.invoke(AlwaysFilter.INSTANCE, new CustomEP());
I get the desired results. Please help me with the details why it is happening this way when the return type of the processAll is a Map.
Thanks a lot!
Regards,
S

Answer 1

911767 wrote:
Hi Robert and JK,
Thank you for your reply and time!
I could not find these details in any of the documentation that specifies keys passed in the result should be subset of the keys passed to the processAll method. Anyways, my problem is to invoke server-side code (avoid de-serialization) by passing a filter and then create a entirely new map (key and value will be different from the entries extracted from the passed filter) by reading the data from the passed entries. How can I implement it?
I am thinking to use aggregator as they are read-only and faster but again how to implement it using:
public Object aggregate(Set entries){
Again, I am getting an empty Map so is it necessary that the object returned should have keys matching the set of the entries passed to this method.
Secondly, there are other methods such as, finalizeResult() and init() if I extend AbstractAggregator, do I need to implement them and if yes, how? The entries set passed to the aggregate() method may not reside on the same node.
Please advise!
Regards,
SHi S,
the process() return value object, or the entry value objects in the map returned by processAll() can be arbitrary objects. So you just return a map from process(), and return a map as the entry value in the result map from processAll().
The AbstractAggregator has a fairly badly documented contract in the Javadoc (does not properly cover the values received in different scenarios for invocation). You should probably read the section about it in the Coherence book, that explains leveraging AbstractAggregator in significantly more details. It also happens to be in the sample chapter, but I recommend reading the entire book.
I am not sure about the issues relating to posting links to PDFs on Packt's webpage, so I won't do that. Please go to Packt's webpage (http://www.packtpub.com ), look for the Coherence book there and download the sample chapter (or order the book).
In short, all 3 to-be-implemented methods (init(), process(), finalizeResult()) in AbstractAggregator are called both on the server and on the caller side. You can distinguish which side you are on from looking at both the passed in fFinal boolean parameter and the m_fParallel attribute tof the aggregator instance.
There are 3 cases:
- non-parallel aggregation processing extracted values (m_fParallel is false, I don't remember what fFinal is in this case),
- parallel aggregation storage side processing extracted values (if I correctly remember, m_fParallel is true, fFinal is false),
- parallel aggregation caller side processing parallel results (m_fParallel and fFinal are both true).
Depending on which side you are on, the process method takes different object types (on server side it receievs the extracted value, on caller side it receives a parallel result object instance).
You SHOULD NOT override any of the other methods (e.g. aggregate() which you mentioned).
The advantage of this approach is that the AbstractAggregator subclass instance can pass itself off as a parallel-aggregator instance.
You should put together a temporary result in a member attribute of the AbstractAggregator subclass, which also means that it will likely not be thread-safe, but at the moment it is not necessary for it to be thread-safe either as it is called only on a single-thread.
Best regards,
Robert
Edited by: robvarga on Feb 3, 2012 10:38 AM