Hi Hasitha, Yeah, the default TopicOverloadPolicy is BLOCK.
Thank you On Wed, Oct 14, 2015 at 1:06 PM, Hasitha Amal De Silva <[email protected]> wrote: > 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. ) > -- Sasikala Kottegoda *Software Engineer* WSO2 Inc., http://wso2.com/ lean. enterprise. middleware Mobile: +94 774835928/712792401
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
