Re: Integration test failing after upgrade to 1.4
We had a similar issue with a plugin regarding this. I found the solution here on this post from 2012: http://elasticsearch-users.115913.n3.nabble.com/Running-ES-Client-inside-ES-Plugin-td3925864.html Injecting the client in setClient was throwing the AllocationService circular dependency exception. Changing it to retrieve from injector solved the issue. On Monday, November 17, 2014 at 8:52:34 PM UTC-6, Deepak wrote: > > Hi, > > After upgrading to ES 1.4, integration tests for our ES plugin started > failing. The plugin works fine when deployed directly to ES. The issue > seems to be only with integration tests which extend > ElasticsearchIntegrationTest class. > > I have uploaded sample project to recreate the issue @ > https://github.com/dr2014/ES1.4_IntegrationTest_Issue > > There seems to be some problem with how Guice injects Client when > integration tests are executed. > > Any ideas as to how to resolve this issue? > > Thanks, > Deepak > > Partial stacktrace: > > org.elasticsearch.common.inject.CreationException: Guice creation errors: > > 1) Tried proxying org.elasticsearch.discovery.DiscoveryService to support > a circular dependency, but it is not an interface. > while locating org.elasticsearch.discovery.DiscoveryService > for parameter 7 at > org.elasticsearch.discovery.local.LocalDiscovery.(Unknown Source) > while locating org.elasticsearch.discovery.local.LocalDiscovery > while locating org.elasticsearch.discovery.Discovery > for parameter 2 at > org.elasticsearch.discovery.DiscoveryService.(Unknown Source) > while locating org.elasticsearch.discovery.DiscoveryService > for parameter 1 at > org.elasticsearch.cluster.service.InternalClusterService.(Unknown > Source) > while locating org.elasticsearch.cluster.service.InternalClusterService > while locating org.elasticsearch.cluster.ClusterService > for parameter 2 at > org.elasticsearch.action.admin.indices.open.TransportOpenIndexAction.(Unknown > > Source) > while locating > org.elasticsearch.action.admin.indices.open.TransportOpenIndexAction > while locating org.elasticsearch.action.support.TransportAction > annotated with > @org.elasticsearch.common.inject.multibindings.Element(setName=,uniqueId=305) > at _unknown_ > while locating java.util.Map org.elasticsearch.action.support.TransportAction> > for parameter 1 at > org.elasticsearch.client.node.NodeClusterAdminClient.(Unknown Source) > while locating org.elasticsearch.client.node.NodeClusterAdminClient > for parameter 1 at > org.elasticsearch.client.node.NodeAdminClient.(Unknown Source) > while locating org.elasticsearch.client.node.NodeAdminClient > for parameter 2 at > org.elasticsearch.client.node.NodeClient.(Unknown Source) > while locating org.elasticsearch.client.node.NodeClient > while locating org.elasticsearch.client.Client > for parameter 2 at com.tr.es.plugin.TestESRestHandler.(Unknown > Source) > while locating com.tr.es.plugin.TestESRestHandler > > 2) Error injecting constructor, java.lang.IllegalStateException: This is a > proxy used to support circular references involving constructors. The > object we're proxying is not constructed yet. Please wait until after > injection has completed to use this object. > at org.elasticsearch.cluster.InternalClusterInfoService.(Unknown > Source) > while locating org.elasticsearch.cluster.InternalClusterInfoService > while locating org.elasticsearch.cluster.ClusterInfoService > for parameter 3 at > org.elasticsearch.cluster.routing.allocation.AllocationService.(Unknown > Source) > while locating > org.elasticsearch.cluster.routing.allocation.AllocationService > for parameter 2 at > -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/5caebd06-cda7-47ee-95bc-42a24d6446bc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
has_parent slow in filter, fast in query?
We ran into a problem with a slow query. Turns out having a has_child (or
has_parent) query in the "filter" part of a "filtered" query is a lot
slower than having the same has_child filter in the "query" part of the
"filtered" query.
The faster of the two queries runs in under 100ms, while the slower one
takes 250-300ms. I don't understand why these would have different run
times, any ideas?
The index is around 2GB. The child with about 600,000 docs, the parent with
about 3,000,000 docs.
These are the two queries:
Slower:
"query": {
"filtered": {
"filter": {
"and": {
"filters": [
{
"range": {
"price": {
"gt": "0"
}
}
},
{
"has_parent": {
"type": "product",
"query": {
"match_all": {}
}
}
}
]
}
}
}
}
Faster:
"query": {
"filtered": {
"query": {
"has_parent": {
"type": "product",
"query": {
"match_all": {}
}
}
},
"filter": {
"and": {
"filters": [
{
"range": {
"price": {
"gt": "0"
}
}
}
]
}
}
}
}
--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to elasticsearch+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/d811bca1-9798-49c5-b1f6-79cb5857f547%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
