Re: Problem with "long" type field

April 2015 02:24:18 UTC-4, Stabaoc wrote: > > So I can't use Java Api? > > 在 2015年4月29日星期三 UTC+8上午11:43:42，Igor Motov写道： >> >> It typically happens if you put data into elasticsearch using Sense or >> some other JavaScript-based applications. Large numbers

Re: Problem with "long" type field

It typically happens if you put data into elasticsearch using Sense or some other JavaScript-based applications. Large numbers like this one are getting rounded in JavaScript before they reach Elasticsearch. Please see https://github.com/elastic/elasticsearch/issues/5518#issuecomment-38540645 f

Re: exists filter broken on 1.5.0 with restored index?

;, and the > 1.4.1 cluster also has "created" : "1000199" > > On Wednesday, March 25, 2015 at 4:45:30 PM UTC+1, Igor Motov wrote: >> >> Hi Mads Martin, >> >> Could you check the version that is returned when you run curl >>

Re: exists filter broken on 1.5.0 with restored index?

Hi Mads Martin, Could you check the version that is returned when you run curl "localhost:9200/my_own_index/_settings?pretty". The version will be in "version" : { "created" : "XXX" } Could you compare it to the version that is returned by the same index in the p

Re: What is the best practice for periodic snapshotting with awc-cloud+s3

Having too many snapshots is problematic. Each snapshot is done in incremental manner, so in order to figure out what changes and what is available all snapshots in the repository needs to be scanned, which takes time as number of snapshots growing. I would recommend pruning old snapshots as ti

Re: Snapshots don't get compressed

There were two reasons for not enabling compression on data files. First of all, the way "chunking" in snapshot/restore API was implemented didn't allow simple implementation of compression on data files. Moreover, the data files are already compressed to a certain degree. In my tests I was get

Re: Data loss after network disconnect

How were these nodes doing in terms of available heap space before the disconnects occurred? On Wednesday, September 10, 2014 6:26:19 AM UTC-4, Israel Tsadok wrote: > > A temporary network disconnect of the master node caused a torrent of > RELOCATING shards, and then one shard remained UNASSIG

Re: Snapshot compress not compressing?

At the moment, compression is applied only to metadata files (index mapping and settings basically). Data files are not compressed. On Monday, September 8, 2014 5:22:09 AM UTC-4, Russell Seymour wrote: > > Good morning, > > I experienced the exact same issue on Friday as well. > > I have an Elas

Re: does snapshot restore lead to a memory leak?

So, you are running out of threads not memory. Are you re-registering repository every time you restore from it? If you do, you might be running into this issue https://github.com/elasticsearch/elasticsearch/issues/6181 On Thursday, July 3, 2014 2:06:38 PM UTC-4, JoeZ99 wrote: > > Igor. > I'm po

Re: does snapshot restore lead to a memory leak?

So, your "search-only" machines are running out of memory, while your "index-only" machines are doing fine. Did I understand you correctly? Could you send me nodes stats (curl "localhost:9200/_nodes/stats?pretty") from the machine that runs out of memory, please run stats a few times with 1 hou

Re: does snapshot restore lead to a memory leak?

Just to make sure I got it right, you really meant 700 restores (not just 700 snapshots), correct? What type of repository are you using? Could you add a bit more details about your use case? On Monday, June 30, 2014 8:53:10 AM UTC-4, JoeZ99 wrote: > > We have one one-machine cluster with about

Re: Can't stop a snapshot running on my cluster

com/imotov/elasticsearch-snapshot-cleanup On Saturday, May 24, 2014 2:53:27 PM UTC-4, Andrew Vos wrote: > > Well it's the only way I can do it without downtime. Unless of course by > "full cluster restart" you mean restarting one node at a time? > > > On Sat,

Re: Can't stop a snapshot running on my cluster

06 PM UTC-4, Andrew Vos wrote: >>> >>> Right ok here's the cluster state https://gist.github.com/ >>> AndrewVos/29de3c6735bbd7808a81 >>> >>> >>> On Sat, May 24, 2014 at 7:18 PM, Andrew Vos wrote: >>> >>>> 1.0.0. What do you mean by

Re: Can't stop a snapshot running on my cluster

.com/AndrewVos/29de3c6735bbd7808a81 > > > On Sat, May 24, 2014 at 7:18 PM, Andrew Vos wrote: > >> 1.0.0. What do you mean by state exactly? >> >> >> On Sat, May 24, 2014 at 6:33 PM, Igor Motov wrote: >> >>> Which version of elsticsearch are you using? Ca

Re: Can't stop a snapshot running on my cluster

might not want to share publicly (index mappings). If this is the case, please feel free to send it to me by email. Igor On Saturday, May 24, 2014 2:18:14 PM UTC-4, Andrew Vos wrote: > > 1.0.0. What do you mean by state exactly? > > > On Sat, May 24, 2014 at 6:33 PM, Igor Moto

Re: Can't stop a snapshot running on my cluster

Which version of elsticsearch are you using? Can you send me the current cluster state? On Saturday, May 24, 2014 10:17:43 AM UTC-4, Andrew Vos wrote: > > A few days ago I started a snapshot, but instead of using a shared network > I used the local filesystem. Because my root partition only had

Re: Snapshot Duration increasing over time

Hi Dipesh, I have a few questions. Are you still on S3? Which version of elasticsearch are you using? How many snapshots do you currently keep in S3? How fast is your index growing over time? Igor On Wednesday, May 7, 2014 6:58:05 AM UTC-4, Dipesh Patel wrote: > > Hi > > We've noticed recently

Re: transport.tcp.port doesn't work for localhost?

You should specify the same cluster name for both node and transport client. It looks like they are running in different clusters: [2014-04-02 15:19:23,262][WARN ][org.elasticsearch.client.transport] [Humus Sapien] node [#transport#-1][d][inet[localhost/127.0.0.1:9300]] not part of the cluster

Re: transport.tcp.port doesn't work for localhost?

e 2014 15:06:04 UTC+1, Igor Motov ha scritto: >> >> You are starting local node, which is using local transport, which is not >> listening on port 9300. The log message that you see is from transport >> client that tries to connect to port 9300 but cannot. Try starting ju

Re: wait_for_completion doesn't seem to be working when making a snapshot

The wait_for_completion flag has to be specified on URL not in the body. Try this: curl -XPUT " http://localhost:9200/_snapshot/backup/snapshot_kibana?wait_for_completion=true&pretty" -d '{ "indices": "kibana-int", "ignore_u

Re: transport.tcp.port doesn't work for localhost?

You are starting local node, which is using local transport, which is not listening on port 9300. The log message that you see is from transport client that tries to connect to port 9300 but cannot. Try starting just your node and you will be see that nobody listens on port 9300. On Tuesday, Ap

Re: Getting "connections idle , closing" log on running facet-script

Vineeth, The script plugin is not using Apache http client. Are you using it in your code? Igor On Tuesday, March 25, 2014 11:02:48 AM UTC-4, vineeth mohan wrote: > > > Hi , > > While running a script using - > https://github.com/imotov/elasticsearch-facet-script > > I am seeing following erro

Re: DELETE snapshot request (which was long-running and had not yet completed) is hung

ad "PUT only permissions". > > Regards, > Swaroop > > > 10.03.2014, 17:40, "Igor Motov" >: > > That's strange. Wrong S3 permissions should have caused it to failed > immediately. Could you provide any more details about the permissio

Re: DELETE snapshot request (which was long-running and had not yet completed) is hung

That's strange. Wrong S3 permissions should have caused it to failed immediately. Could you provide any more details about the permissions, so I can reproduce it? Meanwhile, restarting the nodes where primary shards of the stuck index are located is the only option that I can think of. We are