[
https://issues.apache.org/jira/browse/USERGRID-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Johnson updated USERGRID-1283:
------------------------------------
Description:
Changes related to management app / startup logic
1) Lock Manager setup now happens in the EntityManagerFactory and is invoked as
part of the normal /database/setup process.
2) CpEntityManagerFactory now checks for the existence of the management app
and will retry if it cannot be found, unless Usergrid has not yet been
bootstrapped. It will log the root cause exception and a track trace. Max
retries and interval are configurable.
3) CpEntityManagerFactory now keeps a "cache" of the latest fetched Management
App object. EntityManager cache will update the cached Management App object
whenever it is successfully fetched.
4) CpEntityManagerFactory's cache of EntityManagers will not cache bad
EntityManagers, i.e. those that cannot fetch their own applications, or the
application's name is null.
5) EntityManager cache size configurable via a new property
''entity.manager.cache.size"
6) Additional logging for when EntityManager, EntityManagerFactory,
QueueManager or QueueManagerFactory is null.
was:
Sometimes during Usergrid operation there is a temporary problem connecting to
Cassandra. This can cause some requests to fail (with HTTP 500) and cause bad
values (e.g. EntityManagers with application = null) to be cached. If
connectivity problems happen during startup, Usergrid may start but be unable
to respond to requests without errors.
Usergrid should be more resilient to such temporary connectivity problems:
- Change startup to retry Cassandra until it becomes available
- Cache a copy of the ManagementApp because its needed for almost request
- Change cache to prevent caching of bad EntityManagers
Test these scenarios:
- case 1: startup with no Cassandra running
- case 2: startup with Cassandra starting 30s after Usergrid starts
- case 3: startup where Cassandra goes down after start of Lock Manager, but
before EMF init
- case 3.1: Cassandra comes back before max retries
- case 3.2: Cassandra never comes back
PR is ready for review here: https://github.com/apache/usergrid/pull/528
> Improve ServiceManager.init() start-up logic
> --------------------------------------------
>
> Key: USERGRID-1283
> URL: https://issues.apache.org/jira/browse/USERGRID-1283
> Project: Usergrid
> Issue Type: Improvement
> Affects Versions: 2.1.0
> Reporter: David Johnson
> Assignee: David Johnson
> Fix For: 2.1.1
>
>
> Changes related to management app / startup logic
> 1) Lock Manager setup now happens in the EntityManagerFactory and is invoked
> as part of the normal /database/setup process.
> 2) CpEntityManagerFactory now checks for the existence of the management app
> and will retry if it cannot be found, unless Usergrid has not yet been
> bootstrapped. It will log the root cause exception and a track trace. Max
> retries and interval are configurable.
> 3) CpEntityManagerFactory now keeps a "cache" of the latest fetched
> Management App object. EntityManager cache will update the cached Management
> App object whenever it is successfully fetched.
> 4) CpEntityManagerFactory's cache of EntityManagers will not cache bad
> EntityManagers, i.e. those that cannot fetch their own applications, or the
> application's name is null.
> 5) EntityManager cache size configurable via a new property
> ''entity.manager.cache.size"
> 6) Additional logging for when EntityManager, EntityManagerFactory,
> QueueManager or QueueManagerFactory is null.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
