we have some JUnit based integration tests in which we basically setup a
clean system, create a river and do some index operations like
inserting/updating documents. We are not using ElasticSearchIntegrationTest
but are running our tests against a dedicated cluster.
In the setup which is performed before every test run we do the following:
remove jdbc river from last test run
remove index from last test run
truncate all tables in database
We are facing the issue that step 3 sometimes blocks because there is an
open connection from the river.
The deletion is performed by this code:
DeleteMappingResponse response = client.admin().indices()
.prepareDeleteMapping("_river")
.setType(rivername)
.execute()
.actionGet();
return response.isAcknowledged();
Is this a known issue or do we have some misunderstanding of how to deal
with river deletion?
May it be the case that the table truncation is performed when the river
deletion isn't fully completed? If so, is there a way to wait until river
deletion completed?
we have some JUnit based integration tests in which we basically setup a
clean system, create a river and do some index operations like
inserting/updating documents. We are not using ElasticSearchIntegrationTest
but are running our tests against a dedicated cluster.
In the setup which is performed before every test run we do the following:
remove jdbc river from last test run
remove index from last test run
truncate all tables in database
We are facing the issue that step 3 sometimes blocks because there is an
open connection from the river.
The deletion is performed by this code:
DeleteMappingResponse response = client.admin().indices()
.prepareDeleteMapping("_river")
.setType(rivername)
.execute()
.actionGet();
return response.isAcknowledged();
Is this a known issue or do we have some misunderstanding of how to deal
with river deletion?
May it be the case that the table truncation is performed when the river
deletion isn't fully completed? If so, is there a way to wait until river
deletion completed?
we have some JUnit based integration tests in which we basically setup a
clean system, create a river and do some index operations like
inserting/updating documents. We are not using ElasticSearchIntegrationTest
but are running our tests against a dedicated cluster.
In the setup which is performed before every test run we do the following:
remove jdbc river from last test run
remove index from last test run
truncate all tables in database
We are facing the issue that step 3 sometimes blocks because there is an
open connection from the river.
The deletion is performed by this code:
DeleteMappingResponse response = client.admin().indices()
.prepareDeleteMapping("_river")
.setType(rivername)
.execute()
.actionGet();
return response.isAcknowledged();
Is this a known issue or do we have some misunderstanding of how to deal
with river deletion?
May it be the case that the table truncation is performed when the river
deletion isn't fully completed? If so, is there a way to wait until river
deletion completed?
I noticed in the elasticsearch logs:
[2015-02-16 15:25:20,398][INFO ][river.jdbc.RiverMetrics ] pipeline
org.xbib.elasticsearch.plugin.jdbc.RiverPipeline@25042719 complete: river
jdbc/ctv4ch_junit_abid_interview metrics: 1 rows, 0.23379861173437763 mean,
(0.0 0.0 0.0), ingest metrics: elapsed 4 seconds, 0.0 bytes bytes, 0.0
bytes avg, 0 MB/s
[2015-02-16 15:25:20,398][ERROR][river.jdbc.BulkNodeClient] after bulk [1]
error
java.lang.InterruptedException
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1301)
at java.util.concurrent.Semaphore.acquire(Semaphore.java:317)
at
org.elasticsearch.action.bulk.BulkProcessor.execute(BulkProcessor.java:325)
at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.xbib.elasticsearch.plugin.jdbc.client.BulkProcessorHelper.flush(BulkProcessorHelper.java:43)
This seems to occur when the river, which has just been created, is removed
again by the next test run. So it seems the an InterruptedException results
in an open connection remaining.
I did the following: before deletion of river; I wait until the previously
created one did finish (via _river/jdbc//_state. Then I delete.
This seems to work.
Regards,
Abid
Am Montag, 16. Februar 2015 14:43:37 UTC+1 schrieb Abid Hussain:
Are you sure the deletion of a (non-existent) mapping "_river" makes sense?
The given code results in river deletion. If there is a better way to do
so, I would be happy if you could tell me.
What connection is open? Database connection?
Yes, a database connection used by river remains open.
we have some JUnit based integration tests in which we basically setup a
clean system, create a river and do some index operations like
inserting/updating documents. We are not using ElasticSearchIntegrationTest
but are running our tests against a dedicated cluster.
In the setup which is performed before every test run we do the
following:
remove jdbc river from last test run
remove index from last test run
truncate all tables in database
We are facing the issue that step 3 sometimes blocks because there is an
open connection from the river.
The deletion is performed by this code:
DeleteMappingResponse response = client.admin().indices()
.prepareDeleteMapping("_river")
.setType(rivername)
.execute()
.actionGet();
return response.isAcknowledged();
Is this a known issue or do we have some misunderstanding of how to deal
with river deletion?
May it be the case that the table truncation is performed when the river
deletion isn't fully completed? If so, is there a way to wait until river
deletion completed?
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.