Jason, thanks for analysis. Transitional queue was introduced to handle cases, when messages was delivered before membership changes. Sadly, if service is sending messages inside sync_activate, it's really problem. Solutions to problem which I was thinking about: - don't send messages in sync_activate - I don't think it's good solution. - Add something like "final barrier", which is delivered after all services are synchronized - This may probably work - When doing change form transack queue to regular queue, copy messages somehow (what is the correct order? Also totempg must do same thing) Any ideas (other solutions, comments, ....)? Honza jason napsal(a): > Hi All, > With corosync-1.4.5 and openqis-1.1.4, AMF sends messages in its > sync_activate callback. But if AMF is the last service that SYNCV2 to > serve, then those messages will not be sent out. > With some debug I found out that is because of the newly introduced > new_message_queue_trans. If AMF is the last service that SYNCV2 to serve, > messages that sent in sync_activate callback(called by > sync_barrier_handler()) will be hold by new_message_queue_trans queue. Then > sync_barrier_handler() calls sync_synchronization_complete() results in > message queue being changed into new_message_queue. So those AMF messages > in new_message_queue_trans queue will not be sent unless the next round of > SYNCV2 comes. > If AMF is not the last service that SYNCV2 to serv, this issue will not > happen since AMF messages will be flushed by sync barrier message. > So my question is, is this a bug of AMF? It shall not send message in > sync_activate callback? > > > > > _______________________________________________ > discuss mailing list > discuss@xxxxxxxxxxxx > http://lists.corosync.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
