During testing I followed following steps. 1. create a topic subscriber 2. publish 1000 msgs 3. wait until the subscriber get 1000 messages and close 4. now underneath MB will still be leisurely deleting the content of removed messages (with timeouts etc) 5. I shutdown the broker by Ctrl+c 6. Now with my above fixes it will delete all records that needs to be deleted before shutting down.
I can see when the code is at step 6 MB is saying cassandra is down. Thus before returning from the Close() of message store (hence before returning from deactivte of andes service), cassandra service get disappeared. It boils down to an OSGI problem. @Shameera, I have the dependency to the cassandra bundle as you have suggested in the andes bundle. But seems there is a problem still. Any idea why that happens? On Thu, May 1, 2014 at 10:56 AM, Hasitha Hiranya <[email protected]> wrote: > Hi, > > Also in order to stop connection to Cassandra gracefully, we need to do > following. > > cluster.getConnectionManager().shutdown(); > > Thanks > > > On Thu, May 1, 2014 at 10:52 AM, Hasitha Hiranya <[email protected]>wrote: > >> Hi, >> >> I intend to cleanup graceful shutdown code of WSO2 Message Broker in >> following way. We have to do them as a part of fixing shutdown errors. We >> have managed to keep Cassandra until broker service shutdown properly in >> OSGI env, but we see problems due to lack of these. >> >> 1. When shutting down we have to flush >> all pubSubMessageContentRemoverTasks, meaning we have to delete all acked >> messages for topics, otherwise they will never be removed again (After >> shutting down memory is gone). Concern is we have to wait for timeout for >> those messages to happen, which will cause shutting down of MB on hold >> untill all messages are timed out. For now MB will shut down hoping some >> other node will clear them up. >> >> 2. Above argument goes with content removal tasks as well. Merely >> stopping deletion thread will not help. >> >> 3. above two tasks should be done AFTER stopping queue/topic flusher >> threads. >> >> 4. When shutting down we have to clear in-memory message status (for >> message count to be correct). >> >> 5. We have to copy back NQ messages back to GQ. >> >> 6. Flush message counts. >> >> @pamod, >> >> You have a fix to flush the message count before shutdown (As we update >> it per message chunks). Is it committed? If so, where is the code? It >> should come as point 6. >> >> Apart from point 6 have have done other. Testing now. >> >> Thanks >> >> -- >> *Hasitha Abeykoon* >> Software Engineer; WSO2, Inc.; http://wso2.com >> *cell:* *+94 719363063* >> *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> >> >> > > > -- > *Hasitha Abeykoon* > Software Engineer; WSO2, Inc.; http://wso2.com > *cell:* *+94 719363063* > *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> > > -- *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
