Re: retrieve localhost:9200/_aliases using the java api
Logically, I understand that the curl statement cannot be faster. Which is how I reckon that I'm doing something wrong. This is how I am timing my methods (from my own dev machine pointing to a vm) using the Google stopwatch and ticker. *Client connection to myvm:9300 using java:* ClusterStateRequest clusterStateRequest = Requests.clusterStateRequest() .filterRoutingTable(true) .filterNodes(true) .filteredIndices(new String[]{}); clusterStateRequest.listenerThreaded(false); Stopwatch timer1 = new Stopwatch(Ticker.systemTicker()).start(); searcher.getClient().admin().cluster().state(clusterStateRequest).actionGet().getState().metaData(); System.out.println(myvm:9200/_aliases + timer1.stop().elapsedMillis()); = Gets timed at 60-70ms, while curl -o /dev/null -s -w %{time_total}\\n myvm:9200/_aliases gets timed at 7ms *Client connection to myvm:9300 using java:* Stopwatch timer = new Stopwatch(Ticker.systemTicker()).start(); MapString, IndexStats indices = searcher.getClient().admin().indices().prepareStats().clear().get().getIndices(); System.out.println(myvm:9200/_stats : + timer.stop().elapsedMillis()); = gets timed to 25-35ms, while curl -o /dev/null -s -w %{time_total}\\n 10.40.1.218:9200/_stats gets timed to 20-30ms As you can see, the latter gets similar timings in both java and curl, while the former gets very different timings for what the code inspired by the class RestGetIndicesAliasesAction. The other example, I cannot use. I consistently get an empty map back even if I replace the null with a string. Emilie On Tuesday, January 21, 2014 5:24:26 PM UTC-5, Jörg Prante wrote: Yes, asking the cluster state is possible to filter out for aliases (that is what the TransportGetAliasesAction is doing, too) I was using 1.0.0.RC1, RestGetIndicesAliasAction is deprecated in 1.0.0.RC1 A null argument to GetAliasesRequest gives an NPE, but an empty string works: GetAliasesRequest getAliasesRequest = new GetAliasesRequest(); GetAliasesResponse response = client.admin().indices().getAliases(getAliasesRequest).actionGet(); logger.info({}, response.getAliases()); The curl command can not be faster simply because it calls the Java action in the background, o I'm wondering what timestamps you are measuring. Jörg -- 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/8439c42d-0447-452a-9c5a-c1c737f2260f%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: WARNING failed to prepare/warm after upgrading from 0.90.3 to 0.90.10
I'm having the same problem and would really love to know if there's a fix for it. On Friday, January 17, 2014 4:53:00 AM UTC-5, Benoît wrote: Am I the only one to have this warning ? This make me not confident to upgrade to 0.90.10, should I open an issue ? Benoît On Thursday, January 16, 2014 5:49:24 PM UTC+1, Benoît wrote: Hello, I'm making some test to upgrade from 0.90.3 to 0.90.10 Everything looks good except the following warning in log, below two examples. [2014-01-16 17:27:00,669][WARN ][index.engine.robin ] [integration] [m112][0] failed to prepare/warm java.lang.IllegalMonitorStateException at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:485) at org.elasticsearch.search.SearchService$SearchWarmer$2.awaitTermination(SearchService.java:822) at org.elasticsearch.indices.warmer.InternalIndicesWarmer.warm(InternalIndicesWarmer.java:99) at org.elasticsearch.index.engine.robin.RobinEngine$RobinSearchFactory.newSearcher(RobinEngine.java:1652) at org.apache.lucene.search.SearcherManager.getSearcher(SearcherManager.java:155) at org.apache.lucene.search.SearcherManager.init(SearcherManager.java:89) at org.elasticsearch.index.engine.robin.RobinEngine.buildSearchManager(RobinEngine.java:1530) at org.elasticsearch.index.engine.robin.RobinEngine.start(RobinEngine.java:277) at org.elasticsearch.index.shard.service.InternalIndexShard.performRecoveryPrepareForTranslog(InternalIndexShard.java:660) at org.elasticsearch.index.gateway.local.LocalIndexShardGateway.recover(LocalIndexShardGateway.java:201) at org.elasticsearch.index.gateway.IndexShardGatewayService$1.run(IndexShardGatewayService.java:174) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) [2014-01-16 11:17:36,836][WARN ][index.engine.robin ] [sissor2-pp] [m105][0] failed to prepare/warm java.lang.IllegalMonitorStateException at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:503) at org.elasticsearch.search.SearchService$SearchWarmer$2.awaitTermination(SearchService.java:822) at org.elasticsearch.indices.warmer.InternalIndicesWarmer.warm(InternalIndicesWarmer.java:99) at org.elasticsearch.index.engine.robin.RobinEngine$RobinSearchFactory.newSearcher(RobinEngine.java:1652) at org.apache.lucene.search.SearcherManager.getSearcher(SearcherManager.java:155) at org.apache.lucene.search.SearcherManager.init(SearcherManager.java:89) at org.elasticsearch.index.engine.robin.RobinEngine.buildSearchManager(RobinEngine.java:1530) at org.elasticsearch.index.engine.robin.RobinEngine.start(RobinEngine.java:277) at org.elasticsearch.index.shard.service.InternalIndexShard.performRecoveryPrepareForTranslog(InternalIndexShard.java:660) at org.elasticsearch.indices.recovery.RecoveryTarget$PrepareForTranslogOperationsRequestHandler.messageReceived(RecoveryTarget.java:389) at org.elasticsearch.indices.recovery.RecoveryTarget$PrepareForTranslogOperationsRequestHandler.messageReceived(RecoveryTarget.java:363) at org.elasticsearch.transport.netty.MessageChannelHandler$RequestHandler.run(MessageChannelHandler.java:270) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:722) Anybody encounter this problem ? Thanks. Benoît -- 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/82c8d3cb-e867-45aa-9b5a-2af42cda642f%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: retrieve localhost:9200/_aliases using the java api
Thanks, Jôrg's tip didn't work. Null was not accepted in the constructor. We might be using a different version of ElasticSearch. However, I did find the 0.90.10 equivalent of the class Ivan suggested. I'm guessing that's as close as I can get to reproducing the _alias request. I tried to reproduce it this way (for some reason the action listener version was not firing for me.. - must have missed something - so I'm using actionGet() instead): ClusterStateRequest clusterStateRequest = Requests.clusterStateRequest() .filterRoutingTable(true) .filterNodes(true) .filteredIndices(new String[]{}); clusterStateRequest.listenerThreaded(false); client.admin().cluster().state(clusterStateRequest).actionGet().getState().metaData(); Sadly, it was not as fast as what I'm seeing with the curl statement. In fact, the following call turned out to be faster than the one above and is what I will be using for now. It's still about 40ms slower than the curl _alias call, but it's better than the 80ms I was getting with my initial query. :) client.admin().indices().prepareStats().clear().get().getIndices(); On Tuesday, January 21, 2014 2:59:11 PM UTC-5, Ivan Brusic wrote: The easiest way to find out how to use the Java API equivalent of a REST call is to simply look up the RestAction class. In this case: https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/rest/action/admin/indices/alias/get/RestGetIndicesAliasesAction.javahttps://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/rest/action/admin/indices/alias/get/RestGetIndicesAliasesAction.java?source=c I am on version 0.90.2 and I have been using client.admin().cluster().state(new ClusterStateRequest()).actionGet().getState().getMetaData().aliases() which should be equivalent to yours. Cheers, Ivan On Mon, Jan 20, 2014 at 5:42 PM, Emilie Lavigne emilie@gmail.comjavascript: wrote: Is there a way to reproduce localhost:9200/_aliases using the java api? Our system often needs to request the list of indices available (our indices are organized by date) to identify which days in the query date range have a corresponding index. We are trying to avoid having to cache the list since it may change as our content retention policy cleans up indices. I can retrieve the indices using the following java api call (equivalent of curl localhost:9200/_cluster/state): client.admin().cluster().prepareState().execute().actionGet().getState().metaData() However on our cluster, this call can take up to 80ms, while the curl get request for aliases comes back in 15ms. Obviously, we would prefer to use the latter since the response time is compounded with the search time. I just can't seem to find a way to get that list using java. I've tried this, but the ImmutableOpenMap always comes back empty: ImmutableOpenMapString, ListAliasMetaData aliases = client.admin().indices().getAliases(new IndicesGetAliasesRequest()).actionGet().getAliases(); Any suggestions? Thanks! -- 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 elasticsearc...@googlegroups.com javascript:. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/f91edcaf-5ce9-4d92-9aa0-61bd530a21d4%40googlegroups.com . For more options, visit https://groups.google.com/groups/opt_out. -- 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/566e74a3-8419-42d7-8d16-20ccaecab461%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.