We noticed some delays in processing messages in a polling container (with GS 9.0.2) and I made the following code in an attempt to pinpoint where it happens:
@TriggerHandler
TriggerOperationHandler triggerHandler() {
ReadTriggerOperationHandler triggerHandler = new ReadTriggerOperationHandler() {
@Override
public Object triggerReceive(Object template, GigaSpace gigaSpace, long receiveTimeout) throws DataAccessException {
final Object o = super.triggerReceive(template, gigaSpace, receiveTimeout);
log.info("Triggered "+o);
return o;
}
};
return triggerHandler;
}
@ReceiveHandler
ReceiveOperationHandler receiveHandler() {
return new SingleReadReceiveOperationHandler() {
@Override
protected Object doReceiveBlocking(Object template, GigaSpace gigaSpace, long receiveTimeout) throws DataAccessException {
Object o = super.doReceiveBlocking(template, gigaSpace, receiveTimeout);
log.info("ReceivedB "+o);
return o;
}
@Override
protected Object doReceiveNonBlocking(Object template, GigaSpace gigaSpace) throws DataAccessException {
final Object o = super.doReceiveNonBlocking(template, gigaSpace);
log.info("ReceivedN "+o);
return o;
}
};
}
@SpaceDataEvent
public MessageWrapper processMessage(final MessageWrapper message, final GigaSpace gigaSpace) {
log.info("Entered "+(++i)+" processing " + message);
and got the following after running for a while:
05 Nov 2015 16:40:31,854 JST INFO [GS-orderMessageProcessor-1] [OrderMessageProcessor] Triggered MessageWrapper{7004.T}
05 Nov 2015 16:40:31,915 JST INFO [GS-orderMessageProcessor-1] [OrderMessageProcessor] ReceivedB MessageWrapper{7004.T}
05 Nov 2015 16:40:31,915 JST INFO [GS-orderMessageProcessor-1] [OrderMessageProcessor] Entered 234247 processing MessageWrapper{7004.T}
We were using the @ReceiveHandler before in order to use Read but we had delays even before when we were using the default polling receive handler. MessageWrapper is processed FIFO mode with a basic index on some field that has no relation with timing - a random message id revived on inbound that we use in a different query.
I added the @TriggerHandler only for this logging experiment.
Questions:
- is this test relevant anyway?
- why is there the delay between Triggerd and Received increasing with time/number of processed messages?
- what can we do about it? (without switching approach to passArrayAsIs or concurrentConsummers or anything that different)
Additional question: can we use MultiReadReceiveOperationHandler while still processing with @SpaceDataEvent in a one by one manner? Any hope for latency improvement by doing that?
Thanks
↧