https://redmine.dataone.org/https://redmine.dataone.org/favicon.ico2016-11-16T22:01:23ZDataONE TasksInfrastructure - Task #7935: Use a dedicated hazelcast queue as the listener to generate index taskhttps://redmine.dataone.org/issues/7935?journal_id=282042016-11-16T22:01:23ZJing Taotao@nceas.ucsb.edu
<ul></ul><p>Besides the synchronization, what other scenario do we need to put the system metadata into the dedicated queue?</p>
Infrastructure - Task #7935: Use a dedicated hazelcast queue as the listener to generate index taskhttps://redmine.dataone.org/issues/7935?journal_id=282382016-12-01T23:54:43ZDave Vieglaisdave.vieglais@gmail.com
<ul><li><strong>Target version</strong> changed from <i>CCI-2.3.1</i> to <i>CCI-2.3.2</i></li></ul> Infrastructure - Task #7935: Use a dedicated hazelcast queue as the listener to generate index taskhttps://redmine.dataone.org/issues/7935?journal_id=283402017-01-11T23:45:57ZRob Nahfrnahf@epscor.unm.edu
<ul></ul><p>The current operational structure (sync on UCSB and index on ORC) doesn't allow us to have sync generate index tasks in the local postgres DB.</p>
<p>In an orderly start, the index generator is started after tomcat (owner of HZ system metadata map), but tomcat restarts, and maybe even network partitioning issues might lead to a the index generator hearing a lot of spurious map add events.</p>
<p>Gaining this independence might be accomplished by creating a Hazelcast "SystemMetadataUpdated" list/set or map that is only added to by synchronization and the API update methods The indexTaskGenerator would be listening to this data structure on ORC. Not sure if it solves the network partitioning issue. </p>
Infrastructure - Task #7935: Use a dedicated hazelcast queue as the listener to generate index taskhttps://redmine.dataone.org/issues/7935?journal_id=285442017-02-27T18:07:35ZJing Taotao@nceas.ucsb.edu
<ul><li><strong>Target version</strong> changed from <i>CCI-2.3.2</i> to <i>CCI-2.4.0</i></li></ul>