the keepAlive kicks in after the start() has successfully obtained the lock, so a slave should just block, but a master should check the lock status every period. By default it does an update using the connection that has a pending transaction. It may be that that update has no need to hit the server till a commit... not sure. May depend on the driver. But it should be sufficient to validate the jdbc connection.
Have peek at the source: http://svn.apache.org/viewvc/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/store/jdbc/DefaultDatabaseLocker.java?view=markup On 25 May 2012 13:36, Alex Hooper <[email protected]> wrote: > Gary Tully uttered: > [snip] > >> >> In your setup, it is odd that the dropped connection does not cause >> the lock keepAlive to fail and the broker to terminate. It should, >> unless there are tcp level options that need to kick in to see the >> half close. Or some connection pool config that can pick up on the >> failure, there are some validate options on commons jdbc pool that >> could help there. >> > [snip] > >> Hopefully the above will help, but start with determining why in your >> current setup, the lock keepalive is not triggering for you when the >> connection is dropped because that is a little odd. unless you have >> the >> org.apache.activemq.store.jdbc.JDBCPersistenceAdapter#setLockKeepAlivePeriod >> = 0. >> > > > How exactly does the lock keepalive mechanism work? I'm explicitly set it in > the xml config now: > > <jdbcPersistenceAdapter brokerName="prod-s01" > dataDirectory="${activemq.base}/data" dataSource="#oracle-ds" > useDatabaseLock="true" lockKeepAlivePeriod="10"> > <statements> > <statements stringIdDataType="VARCHAR(128)" /> > </statements> > </jdbcPersistenceAdapter> > > But once the instance has started and issued its initial lock-requesting > query, there is no further TCP activity at all. Maybe I've misunderstood the > intent of this function; that's far from unlikely. > > Alex. > > > >> >> On 24 May 2012 11:45, Alex Hooper <[email protected]> wrote: >>> >>> Hi, >>> >>> We are running activemq 5.5.1 in an active/passive failover configuration >>> with JDBC Persistence to an Oracle backend. The default strategy for >>> determining whether the current master has failed is for the secondary >>> server to attempt to get a lock on the database table, waiting >>> indefinitely >>> for the lock to be granted. >>> >>> This is not working (at least in our context) as, after a relatively >>> short >>> time in operation (a handful of hours at most) the connection to Oracle >>> is >>> dropped. Activemq doesn't notice this, so the secondary sits there >>> happily >>> waiting for a lock it can now never get and, in the event of a failure, >>> won't serve any clients as it is not a master. >>> >>> Is there some way to change the decision mechanism to, eg, a polling >>> strategy? Or can anyone suggest another resolution to this problem? >>> >>> Alex. >>> -- >>> Alex Hooper >>> Operations Team Leader, BMJ Group, BMA House, London WC1H 9JR >>> Tel: +44 (0) 20 7383 6049 >>> http://group.bmj.com/ >>> >>> _______________________________________________________________________ >>> The BMJ Group is one of the world's most trusted providers of medical >>> information for doctors, researchers, health care workers and patients >>> group.bmj.com. This email and any attachments are confidential. If you >>> have received this email in error, please delete it and kindly notify us. >>> If the email contains personal views then the BMJ Group accepts no >>> responsibility for these statements. The recipient should check this >>> email >>> and attachments for viruses because the BMJ Group accepts no liability >>> for >>> any damage caused by viruses. Emails sent or received by the BMJ Group >>> may >>> be monitored for size, traffic, distribution and content. BMJ Publishing >>> Group Limited trading as BMJ Group. A private limited company, >>> registered >>> in England and Wales under registration number 03102371. Registered >>> office: >>> BMA House, Tavistock Square, London WC1H 9JR, UK. >>> _______________________________________________________________________ >> >> >> >> > > > -- > Alex Hooper > Operations Team Leader, BMJ Group, BMA House, London WC1H 9JR > Tel: +44 (0) 20 7383 6049 > http://group.bmj.com/ > > _______________________________________________________________________ > The BMJ Group is one of the world's most trusted providers of medical > information for doctors, researchers, health care workers and patients > group.bmj.com. This email and any attachments are confidential. If you > have received this email in error, please delete it and kindly notify us. > If the email contains personal views then the BMJ Group accepts no > responsibility for these statements. The recipient should check this email > and attachments for viruses because the BMJ Group accepts no liability for > any damage caused by viruses. Emails sent or received by the BMJ Group may > be monitored for size, traffic, distribution and content. BMJ Publishing > Group Limited trading as BMJ Group. A private limited company, registered > in England and Wales under registration number 03102371. Registered office: > BMA House, Tavistock Square, London WC1H 9JR, UK. > _______________________________________________________________________ -- http://fusesource.com http://blog.garytully.com
