activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Tully <gary.tu...@gmail.com>
Subject Re: change strategy for determining failure of primary in JBDC-backed setup
Date Fri, 25 May 2012 13:17:03 GMT
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 <ahooper@bmjgroup.com> 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 <ahooper@bmjgroup.com> 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

Mime
View raw message