Re: Integration test failing after upgrade to 1.4

[James Ekstrom]

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.init(Unknown Source)
   while locating org.elasticsearch.discovery.local.LocalDiscovery
   while locating org.elasticsearch.discovery.Discovery
 for parameter 2 at 
 org.elasticsearch.discovery.DiscoveryService.init(Unknown Source)
   while locating org.elasticsearch.discovery.DiscoveryService
 for parameter 1 at 
 org.elasticsearch.cluster.service.InternalClusterService.init(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.init(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.Maporg.elasticsearch.action.GenericAction, 
 org.elasticsearch.action.support.TransportAction
 for parameter 1 at 
 org.elasticsearch.client.node.NodeClusterAdminClient.init(Unknown Source)
   while locating org.elasticsearch.client.node.NodeClusterAdminClient
 for parameter 1 at 
 org.elasticsearch.client.node.NodeAdminClient.init(Unknown Source)
   while locating org.elasticsearch.client.node.NodeAdminClient
 for parameter 2 at 
 org.elasticsearch.client.node.NodeClient.init(Unknown Source)
   while locating org.elasticsearch.client.node.NodeClient
   while locating org.elasticsearch.client.Client
 for parameter 2 at com.tr.es.plugin.TestESRestHandler.init(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.init(Unknown 
 Source)
   while locating org.elasticsearch.cluster.InternalClusterInfoService
   while locating org.elasticsearch.cluster.ClusterInfoService
 for parameter 3 at 
 org.elasticsearch.cluster.routing.allocation.AllocationService.init(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?

[James Ekstrom]

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.