Hi Sasikala, 2. In case the producing node is attempting an over-write on the buffer, hold it until the buffer is processed. (flow control for subscriptions..)
This is provided by default configurations of Hazelcast 'RealiableTopic' as per [1] So the default TopicOverloadPolicy is BLOCK in an overwrite scenario ? if not that would be the ideal setting IMO. Thanks On Wed, Oct 14, 2015 at 9:53 AM, Sasikala Kottegoda <[email protected]> wrote: > Hi Hasitha, > > Please find the comments in line for the ways of handling the issue. > > 1. Come to a default balance between the buffer size (currently 1000) and > the TTL value for each item in buffer (seconds) / make this configurable. > > I don't think there is an impact of the ring buffer size on the expiration > of items. Increasing the TTL seems the only solution. But we did not > increase this since we needed to avoid the possibility of getting old > notifications in the case of a network failure or a crashed node. Making > the TTL configurable seems like a good solution. > > 2. In case the producing node is attempting an over-write on the buffer, > hold it until the buffer is processed. (flow control for subscriptions..) > > This is provided by default configurations of Hazelcast 'RealiableTopic' > as per [1] > > [1] > http://docs.hazelcast.org/docs/latest-dev/manual/html/reliabletopic.html#reliable-topic-configuration > > Thank you > > On Tue, Oct 13, 2015 at 8:07 PM, Hasitha Amal De Silva <[email protected]> > wrote: > >> increasing the Time-to-Live value [1] from 1 second to about 30 seconds >> got rid of this issue for my scenario. This exception can only occur if the >> item is expired or had been rewritten within the buffer as per [2]. >> >> 2 ways to properly handle this as I can think : >> >> 1. Come to a default balance between the buffer size (currently 1000) and >> the TTL value for each item in buffer (seconds) / make this configurable. >> 2. In case the producing node is attempting an over-write on the buffer, >> hold it until the buffer is processed. (flow control for subscriptions..) >> >> For me, the issue was reproduced by creating about 400 durable JMS topic >> subscriptions with a ramp time of about 2 seconds from Jmeter. >> >> [1] : http://blog.hazelcast.com/ringbuffer-data-structure/ >> [2] : >> http://docs.hazelcast.org/docs/3.5/javadoc/com/hazelcast/ringbuffer/StaleSequenceException.html >> >> >> >> On Tue, Oct 6, 2015 at 4:47 PM, Hasitha Hiranya <[email protected]> >> wrote: >> >>> Hi Peter, >>> >>> We are using Hazelcast in our Message Broker project. We are getting >>> following exception when using a iTopic for syncing data. >>> >>> Appreciate any idea why this happen? Are we doing something wrong in our >>> client application? >>> >>> We found code [1] throwing the exception. >>> >>> Oct 06, 2015 4:26:44 PM >>> com.hazelcast.ringbuffer.impl.operations.ReadManyOperation >>> SEVERE: [192.168.1.50]:4000 [wso2.mb.domain] [3.5] sequence:8 is too >>> small. The current headSequence is:9 >>> com.hazelcast.ringbuffer.StaleSequenceException: sequence:8 is too >>> small. The current headSequence is:9 >>> at >>> com.hazelcast.ringbuffer.impl.RingbufferContainer.checkBlockableReadSequence(RingbufferContainer.java:176) >>> at >>> com.hazelcast.ringbuffer.impl.operations.ReadManyOperation.beforeRun(ReadManyOperation.java:55) >>> at >>> com.hazelcast.spi.impl.operationservice.impl.OperationRunnerImpl.run(OperationRunnerImpl.java:131) >>> at >>> com.hazelcast.spi.impl.operationexecutor.classic.OperationThread.processOperation(OperationThread.java:154) >>> at >>> com.hazelcast.spi.impl.operationexecutor.classic.OperationThread.process(OperationThread.java:110) >>> at >>> com.hazelcast.spi.impl.operationexecutor.classic.OperationThread.doRun(OperationThread.java:101) >>> at >>> com.hazelcast.spi.impl.operationexecutor.classic.OperationThread.run(OperationThread.java:76) >>> >>> >>> [1]. >>> https://github.com/hazelcast/hazelcast/blob/master/hazelcast/src/main/java/com/hazelcast/ringbuffer/impl/RingbufferContainer.java >>> >>> Thanks >>> >>> -- >>> *Hasitha Abeykoon* >>> Senior Software Engineer; WSO2, Inc.; http://wso2.com >>> *cell:* *+94 719363063* >>> *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> >>> >>> >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> >> >> -- >> Cheers, >> >> Hasitha Amal De Silva >> Software Engineer >> Mobile : 0772037426 >> Blog : http://devnutshell.tumblr.com/ >> WSO2 Inc.: http://wso2.com ( lean.enterprise.middleware. ) >> > > > > -- > Sasikala Kottegoda > *Software Engineer* > WSO2 Inc., http://wso2.com/ > lean. enterprise. middleware > Mobile: +94 774835928/712792401 > -- Cheers, Hasitha Amal De Silva Software Engineer Mobile : 0772037426 Blog : http://devnutshell.tumblr.com/ WSO2 Inc.: http://wso2.com ( lean.enterprise.middleware. )
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
