# TTL question **URL:** \ **Category:** Elasticsearch\ **Created:** [April 1, 2013, 2:55pm UTC](https://discuss.elastic.co/t/ttl-question/11400 "2013-04-01T14:55:21Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![brian\_yoder](https://avatars.discourse-cdn.com/v4/letter/b/f1d935/32.png) [@brian\_yoder](https://discuss.elastic.co/u/brian_yoder)\ **Post date:** [April 1, 2013, 2:55pm UTC](https://discuss.elastic.co/t/ttl-question/11400/1 "2013-04-01T14:55:21Z")
After digging further into TLL, I do indeed seem to find that mortals (documents with a finite time to live) and immortals (documents with an infinite time to live) cannot coexist within the same document type, but they can coexist within different document types within the same index. The following seems to work. But I'm not quite sure why. I set the overall refresh interval to 5 seconds to make testing easier. So based on the documentation I found, here are the beginnings of my settings and mappings when I create the index: _{_ - "settings" : {\* - "indices" : {\* - ``` "ttl.interval" : "5s"* ``` - }\*, "index" : { "number\_of\_shards" : 1, "refresh\_interval" : "1s", "analysis" : { "char\_filter" : { }, "filter" : { "english\_snowball\_filter" : { "type" : "snowball", "language" : "English" } }, "analyzer" : { "english\_stemming\_analyzer" : { "type" : "custom", "tokenizer" : "standard", "filter" : [ "standard", "lowercase", "asciifolding", "english\_snowball\_filter" ] }, "english\_standard\_analyzer" : { "type" : "custom", "tokenizer" : "standard", "filter" : ["standard", "lowercase", "asciifolding"] } } } } }, ..... And here is what ElasticSearch sees as the index settings. Is index.indices OK? It seems to work fine... no errors, and I certainly seem to notice the 5 second granularity on checking and watching documents disappear. But I don't see any documentation that gives the context for this setting: $ curl -XGET "localhost:9200/mortal/\_settings?pretty=true" { "mortal" : { "settings" : { "index.analysis.filter.english\_snowball\_filter.type" : "snowball", _"index.indices.ttl.interval" : "5s",_ "index.refresh\_interval" : "1s", "index.analysis.analyzer.english\_standard\_analyzer.type" : "custom", "index.analysis.analyzer.english\_stemming\_analyzer.type" : "custom", "index.analysis.analyzer.english\_standard\_analyzer.filter.0" : "standard", "index.number\_of\_shards" : "1", "index.analysis.analyzer.english\_standard\_analyzer.filter.2" : "asciifolding", "index.analysis.analyzer.english\_standard\_analyzer.filter.1" : "lowercase", "index.analysis.filter.english\_snowball\_filter.language" : "English", "index.analysis.analyzer.english\_stemming\_analyzer.filter.2" : "asciifolding", "index.analysis.analyzer.english\_stemming\_analyzer.filter.3" : "english\_snowball\_filter", "index.analysis.analyzer.english\_standard\_analyzer.tokenizer" : "standard", "index.analysis.analyzer.english\_stemming\_analyzer.tokenizer" : "standard", "index.analysis.analyzer.english\_stemming\_analyzer.filter.0" : "standard", "index.analysis.analyzer.english\_stemming\_analyzer.filter.1" : "lowercase", "index.number\_of\_replicas" : "1", "index.version.created" : "200499" } } } Perhaps ES is just being very lenient to me? Thanks in advance before I commit this all to code! -- 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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![brian\_yoder](https://avatars.discourse-cdn.com/v4/letter/b/f1d935/32.png) [@brian\_yoder](https://discuss.elastic.co/u/brian_yoder)\ **Post date:** [April 1, 2013, 3:27pm UTC](https://discuss.elastic.co/t/ttl-question/11400/2 "2013-04-01T15:27:01Z")
Actually, its behavior is to check at the default ttl interval of 60 seconds. I can store the setting, retrieve the setting, but am not sure exactly locate to put the setting. -- 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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![Benjamin\_Deveze](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/benjamin_deveze/32/1577_2.png) [@Benjamin\_Deveze](https://discuss.elastic.co/u/Benjamin_Deveze)\ **Post date:** [April 1, 2013, 4:06pm UTC](https://discuss.elastic.co/t/ttl-question/11400/3 "2013-04-01T16:06:10Z")
I am not sure to understand what is the problem or what you are trying to achieve. Note that mortals and immortals documents can coexist within the same document type. [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/reference/mapping/ttl-field/) can maybe help. To be clearer I think that maybe your problem is that you have set a default TTL value so if you don't provide an explicit TTL value when indexing it will take the default TTL value. If you don't set a default TTL value and you don't set a TTL at index time then your indexed document will be immortal. If you want immortal documents maybe for now you should not set a default TTL and index every mortal documents with an explicite TTL and immortal ones with no TTL. I hope it helps a bit. Maybe we should have a special value to set an infinite TTL value at index time to allow having a default TTL value and when needing to index an immortal document we could use that special value. On Monday, April 1, 2013 4:55:21 PM UTC+2, InquiringMind wrote: > After digging further into TLL, I do indeed seem to find that mortals > (documents with a finite time to live) and immortals (documents with an > infinite time to live) cannot coexist within the same document type, but > they can coexist within different document types within the same index. > > The following seems to work. But I'm not quite sure why. I set the overall > refresh interval to 5 seconds to make testing easier. So based on the > documentation I found, here are the beginnings of my settings and mappings > when I create the index: > > _{_ > > - "settings" : {\* > - "indices" : {\* > - > > ``` > "ttl.interval" : "5s"* > > ``` > > - }\*, > "index" : { > "number\_of\_shards" : 1, > "refresh\_interval" : "1s", > "analysis" : { > "char\_filter" : { }, > "filter" : { > "english\_snowball\_filter" : { > "type" : "snowball", > "language" : "English" > } > }, > "analyzer" : { > "english\_stemming\_analyzer" : { > "type" : "custom", > "tokenizer" : "standard", > "filter" : [ "standard", "lowercase", "asciifolding", > "english\_snowball\_filter" ] > }, > "english\_standard\_analyzer" : { > "type" : "custom", > "tokenizer" : "standard", > "filter" : ["standard", "lowercase", "asciifolding"] > } > } > } > } > }, ..... > > And here is what Elasticsearch sees as the index settings. Is > index.indices OK? It seems to work fine... no errors, and I certainly seem > to notice the 5 second granularity on checking and watching documents > disappear. > > But I don't see any documentation that gives the context for this setting: > > $ curl -XGET "localhost:9200/mortal/\_settings?pretty=true" > { > "mortal" : { > "settings" : { > "index.analysis.filter.english\_snowball\_filter.type" : "snowball", > _"index.indices.ttl.interval" : "5s",_ > "index.refresh\_interval" : "1s", > "index.analysis.analyzer.english\_standard\_analyzer.type" : "custom", > "index.analysis.analyzer.english\_stemming\_analyzer.type" : "custom", > "index.analysis.analyzer.english\_standard\_analyzer.filter.0" : > "standard", > "index.number\_of\_shards" : "1", > "index.analysis.analyzer.english\_standard\_analyzer.filter.2" : > "asciifolding", > "index.analysis.analyzer.english\_standard\_analyzer.filter.1" : > "lowercase", > "index.analysis.filter.english\_snowball\_filter.language" : "English", > "index.analysis.analyzer.english\_stemming\_analyzer.filter.2" : > "asciifolding", > "index.analysis.analyzer.english\_stemming\_analyzer.filter.3" : > "english\_snowball\_filter", > "index.analysis.analyzer.english\_standard\_analyzer.tokenizer" : > "standard", > "index.analysis.analyzer.english\_stemming\_analyzer.tokenizer" : > "standard", > "index.analysis.analyzer.english\_stemming\_analyzer.filter.0" : > "standard", > "index.analysis.analyzer.english\_stemming\_analyzer.filter.1" : > "lowercase", > "index.number\_of\_replicas" : "1", > "index.version.created" : "200499" > } > } > } > > Perhaps ES is just being very lenient to me? > > Thanks in advance before I commit this all to code! -- 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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![brian\_yoder](https://avatars.discourse-cdn.com/v4/letter/b/f1d935/32.png) [@brian\_yoder](https://discuss.elastic.co/u/brian_yoder)\ **Post date:** [April 1, 2013, 5:25pm UTC](https://discuss.elastic.co/t/ttl-question/11400/4 "2013-04-01T17:25:21Z")
> I am not sure to understand what is the problem or what you are trying to > achieve. The one thing I didn't achieve was to change the default TTL check interval from its default of 60s to a smaller value (5s) for testing purposes. But perhaps this is a cluster-wide setting and not a per-index setting? So I am currently thinking I could set a transient value for testing, and then it goes away when my local cluster is restarted so there's no long-term ill effects. In the meantime, though, I can test with the 60 second default interval; I just need to add some automation so I don't have to sit there and count down the minutes! > Note that mortals and immortals documents can coexist within the same > document type. > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/reference/mapping/ttl-field/) can maybe > help. > To be clearer I think that maybe your problem is that you have set a > default TTL value so if you don't provide an explicit TTL value when > indexing it will take the default TTL value. > If you don't set a default TTL value and you don't set a TTL at index time > then your indexed document will be immortal. If you want immortal documents > maybe for now you should not set a default TTL and index every mortal > documents with an explicite TTL and immortal ones with no TTL. My own direct observations with version 0.20.4 is: 1. If I enable ttl for a specific document type and don't set a default value, then the default value is set to 1d (1 day) for me automatically. However, all documents of that type (in that index) will eventually expire due to ttl (mortal). 2. If I don't enable ttl then setting a ttl on a document has no effect: It lives forever (immortal). So I can have one type that has ttl enabled (with a default value that I set, or a default value of 1d if I don't set one myself). Pure mortal; no immortal documents possible. Long-lived, yes. But not truly immortal. And I can have another type with ttl disabled, in which all documents are immortal even if I create or update a document with an explicit \_ttl value. None are ever expired by Elasticsearch's ttl processing in this index and document type. > I hope it helps a bit. > > Maybe we should have a special value to set an infinite TTL value at index > time to allow having a default TTL value and when needing to index an > immortal document we could use that special value. That would be awesome! I know that I could always set the maximum long integer value for a default ttl, but "really really big" isn't truly infinite. An explicit infinite (INF, perhaps) would be a very nice enhancement. 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 [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![Benjamin\_Deveze](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/benjamin_deveze/32/1577_2.png) [@Benjamin\_Deveze](https://discuss.elastic.co/u/Benjamin_Deveze)\ **Post date:** [April 1, 2013, 5:57pm UTC](https://discuss.elastic.co/t/ttl-question/11400/5 "2013-04-01T17:57:06Z")
For your first problem I think you didn't set the ttl.interval value properly as you said it is a cluster setting check [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/reference/api/admin-cluster-update-settings/) to set indices.ttl.interval properly otherwise it will still be 60s as you have seen. I have tested to enable TTL field on 0.20.6 and it does not set a TTL of 1 day by default. Could you show how you enabled TTL? Also you can display the remaining TTL of a document using fields=\_source,\_ttl it can help to debug if you are not aware of that. If the \_ttl field is not returned in response the document is immortal. If you disable TTL as you said all your documents are immortals no matter what TTL you provide. I think an INF value would be nice too. On Monday, April 1, 2013 7:25:21 PM UTC+2, InquiringMind wrote: > I am not sure to understand what is the problem or what you are trying to > > > achieve. > > The one thing I didn't achieve was to change the default TTL check > interval from its default of 60s to a smaller value (5s) for testing > purposes. But perhaps this is a cluster-wide setting and not a per-index > setting? So I am currently thinking I could set a transient value for > testing, and then it goes away when my local cluster is restarted so > there's no long-term ill effects. In the meantime, though, I can test with > the 60 second default interval; I just need to add some automation so I > don't have to sit there and count down the minutes! > > > Note that mortals and immortals documents can coexist within the same > > document type. > > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/reference/mapping/ttl-field/) can > > maybe help. > > To be clearer I think that maybe your problem is that you have set a > > default TTL value so if you don't provide an explicit TTL value when > > indexing it will take the default TTL value. > > If you don't set a default TTL value and you don't set a TTL at index > > time then your indexed document will be immortal. If you want immortal > > documents maybe for now you should not set a default TTL and index every > > mortal documents with an explicite TTL and immortal ones with no TTL. > > My own direct observations with version 0.20.4 is: > > 1. If I enable ttl for a specific document type and don't set a default > value, then the default value is set to 1d (1 day) for me automatically. > However, all documents of that type (in that index) will eventually expire > due to ttl (mortal). > > 2. If I don't enable ttl then setting a ttl on a document has no effect: > It lives forever (immortal). > > So I can have one type that has ttl enabled (with a default value that I > set, or a default value of 1d if I don't set one myself). Pure mortal; no > immortal documents possible. Long-lived, yes. But not truly immortal. > > And I can have another type with ttl disabled, in which all documents are > immortal even if I create or update a document with an explicit \_ttl value. > None are ever expired by Elasticsearch's ttl processing in this index and > document type. > > > I hope it helps a bit. > > > > Maybe we should have a special value to set an infinite TTL value at > > index time to allow having a default TTL value and when needing to index an > > immortal document we could use that special value. > > That would be awesome! I know that I could always set the maximum long > integer value for a default ttl, but "really really big" isn't truly > infinite. An explicit infinite (INF, perhaps) would be a very nice > enhancement. > > 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 [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![brian\_yoder](https://avatars.discourse-cdn.com/v4/letter/b/f1d935/32.png) [@brian\_yoder](https://discuss.elastic.co/u/brian_yoder)\ **Post date:** [April 1, 2013, 6:39pm UTC](https://discuss.elastic.co/t/ttl-question/11400/6 "2013-04-01T18:39:08Z")
> I have tested to enable TTL field on 0.20.6 and it does not set a TTL of 1 > day by default. Could you show how you enabled TTL? Ah, I missed the place in the documentation that says that if no default is provided, the TTL is infinite. My mistake entirely. In that case, INF is a matter of not setting a default and not putting a \_ttl in the document. But, yeah, an explicit per-document INF would cover all of the possibilities, allowing a finite default with an occasional immortal (INF) document. > Also you can display the remaining TTL of a document using > fields=\_source,\_ttl it can help to debug if you are not aware of that. If > the \_ttl field is not returned in response the document is immortal. I did not realize this. Cool! I will do some more digging. In the meantime, thanks so much for your quick answers and patience! -- 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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![brian\_yoder](https://avatars.discourse-cdn.com/v4/letter/b/f1d935/32.png) [@brian\_yoder](https://discuss.elastic.co/u/brian_yoder)\ **Post date:** [April 1, 2013, 8:25pm UTC](https://discuss.elastic.co/t/ttl-question/11400/7 "2013-04-01T20:25:54Z")
One more quick question: > _Also you can display the remaining TTL of a document using > fields=\_source,\_ttl it can help to debug if you are not aware of that. If > the \_ttl field is not returned in response the document is immortal._ I'm setting the per-document "\_ttl" value in the action\_and\_meta\_data line of a \_bulk request, and not as a "\_ttl" field within the source. For example: {"create":{"\_index":"mortal","\_type":"elf","\_id":"3","\_ttl":"3m"}} { "cn" : "Haldir of Lórien" , "text" : [ "Dies in the battle of Helm's Deep", "Gone in 3m" ] } I can't seem to coerce the Java API to show either the value that is set, or the time that remains (preferable). I'm not able to see it in the responses from the getSourceAsString or getSourceAsMap or field(name) methods. Of course, I'm still sure I'm looking in the wrong place or doing something else incorrectly! I haven't yet found a problem that was the fault of Elasticsearch. 😉 Otherwise, everything seems to be working fine. I wrote an automated tool that goes does all the one-minute delays and re-query commands to show the dwindling results as documents are expired. -- 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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![Benjamin\_Deveze](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/benjamin_deveze/32/1577_2.png) [@Benjamin\_Deveze](https://discuss.elastic.co/u/Benjamin_Deveze)\ **Post date:** [April 1, 2013, 9:48pm UTC](https://discuss.elastic.co/t/ttl-question/11400/8 "2013-04-01T21:48:07Z")
Your bulk order seems correct to me. Ok just to be sure: 1. Have you enabled ttl for your mortal index 2. If you are using the java API have you explicitly ask for the \_ttl fields to be returned in response? 3. If it is not 1 or 2 could you post a bit of the code you are using? I like your example btw On Monday, April 1, 2013 10:25:54 PM UTC+2, InquiringMind wrote: > One more quick question: > > > _Also you can display the remaining TTL of a document using > > fields=\_source,\_ttl it can help to debug if you are not aware of that. If > > the \_ttl field is not returned in response the document is immortal._ > > I'm setting the per-document "\_ttl" value in the action\_and\_meta\_dataline of a \_bulk request, and not as a " > \_ttl" field within the source. For example: > > {"create":{"\_index":"mortal","\_type":"elf","\_id":"3","\_ttl":"3m"}} > { "cn" : "Haldir of Lórien" , "text" : [ "Dies in the battle of Helm's > Deep", "Gone in 3m" ] } > > I can't seem to coerce the Java API to show either the value that is set, > or the time that remains (preferable). I'm not able to see it in the > responses from the getSourceAsString or getSourceAsMap or field(name) > methods. Of course, I'm still sure I'm looking in the wrong place or doing > something else incorrectly! I haven't yet found a problem that was the > fault of Elasticsearch. 😉 > > Otherwise, everything seems to be working fine. I wrote an automated tool > that goes does all the one-minute delays and re-query commands to show the > dwindling results as documents are expired. -- 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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![brian\_yoder](https://avatars.discourse-cdn.com/v4/letter/b/f1d935/32.png) [@brian\_yoder](https://discuss.elastic.co/u/brian_yoder)\ **Post date:** [April 1, 2013, 10:00pm UTC](https://discuss.elastic.co/t/ttl-question/11400/9 "2013-04-01T22:00:45Z")
1. Yes. ttl is enabled for both the "ghost" and "elf" types in the mortal index. Expiration behavior is repeatedly correct. 2. Ah... here's where the Javadoc doesn't help. In short, no I don't. But from your question, do I guess that: GetRequestBuilder grb = client.prepareGet(defaultIndex, type, id) _grb.setFields("\_ttl", "\_source");_ At this time, I don't call the setFields method at all. In the response, I call getSourceAsString and then use the built-in Jackson stream parser to create my field name:[values]. I do this because it's a tiny bit faster than going through getSourceAsMap, and this lets me collect the fields in a LinkedHashMap so that the order in the source can be easily preserved. On Monday, April 1, 2013 5:48:07 PM UTC-4, Benjamin Devèze wrote: > Your bulk order seems correct to me. Ok just to be sure: > > 1. Have you enabled ttl for your mortal index > 2. If you are using the java API have you explicitly ask for the \_ttl > fields to be returned in response? > 3. If it is not 1 or 2 could you post a bit of the code you are using? > > I like your example btw -- 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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![Benjamin\_Deveze](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/benjamin_deveze/32/1577_2.png) [@Benjamin\_Deveze](https://discuss.elastic.co/u/Benjamin_Deveze)\ **Post date:** [April 1, 2013, 10:08pm UTC](https://discuss.elastic.co/t/ttl-question/11400/10 "2013-04-01T22:08:44Z")
Yes you have to call setFields On Tuesday, April 2, 2013 12:00:45 AM UTC+2, InquiringMind wrote: > 1. Yes. ttl is enabled for both the "ghost" and "elf" types in the mortal > index. Expiration behavior is repeatedly correct. > > 2. Ah... here's where the Javadoc doesn't help. In short, no I don't. But > from your question, do I guess that: > > GetRequestBuilder grb = client.prepareGet(defaultIndex, type, id) > _grb.setFields("\_ttl", "\_source");_ > > At this time, I don't call the setFields method at all. In the response, > I call getSourceAsString and then use the built-in Jackson stream parser > to create my field name:[values]. I do this because it's a tiny bit faster > than going through getSourceAsMap, and this lets me collect the fields in > a LinkedHashMap so that the order in the source can be easily preserved. > > On Monday, April 1, 2013 5:48:07 PM UTC-4, Benjamin Devèze wrote: > > > Your bulk order seems correct to me. Ok just to be sure: > > > > 1. Have you enabled ttl for your mortal index > > 2. If you are using the java API have you explicitly ask for the \_ttl > > fields to be returned in response? > > 3. If it is not 1 or 2 could you post a bit of the code you are using? > > > > I like your example btw -- 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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![brian\_yoder](https://avatars.discourse-cdn.com/v4/letter/b/f1d935/32.png) [@brian\_yoder](https://discuss.elastic.co/u/brian_yoder)\ **Post date:** [April 2, 2013, 10:23pm UTC](https://discuss.elastic.co/t/ttl-question/11400/11 "2013-04-02T22:23:35Z")
Thanks again, Benjamin, for your help, advice, and patience while I worked my way through the TTL processing. All my tools are now updated correctly and working well. Here is the curl version of the query, after the initial load of 9 ghosts and 3 elves. The ghost type has ttl enabled with a default time to live of 1.9m. The elf type has ttl enabled but with no default which allows both mortals and immortals to coexist in harmony. curl -XGET '[http://localhost:9200/mortal/\_search?pretty=true](http://localhost:9200/mortal/_search?pretty=true)' -d' { "from" : 0, "size" : 20, "query" : { "match\_all" : { } }, "version" : true, "explain" : false, "fields" : ["\_ttl", "\_source"] }' And here is the response from curl. Of course, I prefer the Java way of doing things, but my driver emits the query as JSON as an option. However, I much prefer the ElasticSearch TimeValue class which emits the time in a much prettier format even if handed only milliseconds. (My only complaint is that toString is able to generates suffix values that parseTimeValuecannot handle. But since parseTimeValue-compatible time values are the only things that go in, it's perhaps a bit moot that it's a subset of what can come out.) { "took" : 2, "timed\_out" : false, "\_shards" : { "total" : 1, "successful" : 1, "failed" : 0 }, "hits" : { "total" : 12, "max\_score" : 1.0, "hits" : [ { "\_index" : "mortal", "\_type" : "ghost", "\_id" : "1", "\_version" : 1, "\_score" : 1.0, "\_source" : { "cn" : "The Funky Phantom" , "text" : [ "Gone in 5 seconds" ] }, "fields" : { "\_ttl" : -260 } }, { "\_index" : "mortal", "\_type" : "ghost", "\_id" : "2", "\_version" : 1, "\_score" : 1.0, "\_source" : { "cn" : "Pacman Ghost" , "text" : [ "Gone in 10 seconds" ] }, "fields" : { "\_ttl" : 4740 } }, { "\_index" : "mortal", "\_type" : "ghost", "\_id" : "6", "\_version" : 1, "\_score" : 1.0, "\_source" : { "cn" : "Ghost Dad" , "text" : [ "Gone in 1.8 minutes" ] }, "fields" : { "\_ttl" : 102740 } }, { "\_index" : "mortal", "\_type" : "ghost", "\_id" : "7", "\_version" : 1, "\_score" : 1.0, "\_source" : { "cn" : "Casper the Friendly Ghost" , "text" : ["Gone in 1.8 minutes"] }, "fields" : { "\_ttl" : 102740 } }, { "\_index" : "mortal", "\_type" : "ghost", "\_id" : "3", "\_version" : 1, "\_score" : 1.0, "\_source" : { "cn" : "Ghost of Christmas Present" , "text" : ["Lifetime set to default (1.9m)"] }, "fields" : { "\_ttl" : 108740 } }, { "\_index" : "mortal", "\_type" : "ghost", "\_id" : "4", "\_version" : 1, "\_score" : 1.0, "\_source" : { "cn" : "Ghost of Christmas Past" , "text" : ["Lifetime set to default (1.9m)"] }, "fields" : { "\_ttl" : 108740 } }, { "\_index" : "mortal", "\_type" : "ghost", "\_id" : "5", "\_version" : 1, "\_score" : 1.0, "\_source" : { "cn" : "Jack Skellington" , "text" : [ "Lifetime set to default (1.9m)" ] }, "fields" : { "\_ttl" : 108740 } }, { "\_index" : "mortal", "\_type" : "ghost", "\_id" : "8", "\_version" : 1, "\_score" : 1.0, "\_source" : { "cn" : "Space Ghost" , "text" : [ "Gone in 4 minutes" ] }, "fields" : { "\_ttl" : 234740 } }, { "\_index" : "mortal", "\_type" : "ghost", "\_id" : "9", "\_version" : 1, "\_score" : 1.0, "\_source" : { "cn" : "Boo Berry" , "text" : [ "Gone in 5 minutes" ] }, "fields" : { "\_ttl" : 291740 } }, { "\_index" : "mortal", "\_type" : "elf", "\_id" : "1", "\_version" : 1, "\_score" : 1.0, "\_source" : { "cn" : "Celeborn" , "text" : [ "Lives forever" ] } }, { "\_index" : "mortal", "\_type" : "elf", "\_id" : "2", "\_version" : 1, "\_score" : 1.0, "\_source" : { "cn" : "Galadriel" , "text" : [ "Lives forever" ] } }, { "\_index" : "mortal", "\_type" : "elf", "\_id" : "3", "\_version" : 1, "\_score" : 1.0, _"\_source"_ : { "cn" : "Haldir of Lórien" , "text" : ["Dies in the battle of Helm's Deep", "Gone in 3m"] }, _"fields" : {_ - ``` "_ttl" : 174740* } ``` } ] } } You can perhaps see how I got confused in the beginning. I have to call setFields("\_ttl", "\_source") even though _\_source_ comes back on its own while _"\_ttl"_ comes back in the _"fields"_ JSON object. Just enough to throw me off. But the newsgroups are very friendly and helpful. -- 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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![Benjamin\_Deveze](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/benjamin_deveze/32/1577_2.png) [@Benjamin\_Deveze](https://discuss.elastic.co/u/Benjamin_Deveze)\ **Post date:** [April 2, 2013, 10:30pm UTC](https://discuss.elastic.co/t/ttl-question/11400/12 "2013-04-02T22:30:19Z")
Yeah it can be a bit confusing at first. I'm glad you have made it works! On Wednesday, April 3, 2013 12:23:35 AM UTC+2, InquiringMind wrote: > Thanks again, Benjamin, for your help, advice, and patience while I worked > my way through the TTL processing. All my tools are now updated correctly > and working well. > > Here is the curl version of the query, after the initial load of 9 ghosts > and 3 elves. The ghost type has ttl enabled with a default time to live > of 1.9m. The elf type has ttl enabled but with no default which allows > both mortals and immortals to coexist in harmony. > > curl -XGET '[http://localhost:9200/mortal/\_search?pretty=true](http://localhost:9200/mortal/_search?pretty=true)' -d' > { > "from" : 0, > "size" : 20, > "query" : { > "match\_all" : { } > }, > "version" : true, > "explain" : false, > "fields" : ["\_ttl", "\_source"] > }' > > And here is the response from curl. Of course, I prefer the Java way of > doing things, but my driver emits the query as JSON as an option. However, > I much prefer the Elasticsearch TimeValue class which emits the time in a > much prettier format even if handed only milliseconds. (My only complaint > is that toString is able to generates suffix values that parseTimeValuecannot handle. But since > parseTimeValue-compatible time values are the only things that go in, > it's perhaps a bit moot that it's a subset of what can come out.) > > { > "took" : 2, > "timed\_out" : false, > "\_shards" : { > "total" : 1, > "successful" : 1, > "failed" : 0 > }, > "hits" : { > "total" : 12, > "max\_score" : 1.0, > "hits" : [ { > "\_index" : "mortal", > "\_type" : "ghost", > "\_id" : "1", > "\_version" : 1, > "\_score" : 1.0, "\_source" : { "cn" : "The Funky Phantom" , "text" : > ["Gone in 5 seconds"] }, > "fields" : { > "\_ttl" : -260 > } > }, { > "\_index" : "mortal", > "\_type" : "ghost", > "\_id" : "2", > "\_version" : 1, > "\_score" : 1.0, "\_source" : { "cn" : "Pacman Ghost" , "text" : [ > "Gone in 10 seconds" ] }, > "fields" : { > "\_ttl" : 4740 > } > }, { > "\_index" : "mortal", > "\_type" : "ghost", > "\_id" : "6", > "\_version" : 1, > "\_score" : 1.0, "\_source" : { "cn" : "Ghost Dad" , "text" : [ "Gone > in 1.8 minutes" ] }, > "fields" : { > "\_ttl" : 102740 > } > }, { > "\_index" : "mortal", > "\_type" : "ghost", > "\_id" : "7", > "\_version" : 1, > "\_score" : 1.0, "\_source" : { "cn" : "Casper the Friendly Ghost" , > "text" : ["Gone in 1.8 minutes"] }, > "fields" : { > "\_ttl" : 102740 > } > }, { > "\_index" : "mortal", > "\_type" : "ghost", > "\_id" : "3", > "\_version" : 1, > "\_score" : 1.0, "\_source" : { "cn" : "Ghost of Christmas Present" , > "text" : ["Lifetime set to default (1.9m)"] }, > "fields" : { > "\_ttl" : 108740 > } > }, { > "\_index" : "mortal", > "\_type" : "ghost", > "\_id" : "4", > "\_version" : 1, > "\_score" : 1.0, "\_source" : { "cn" : "Ghost of Christmas Past" , > "text" : ["Lifetime set to default (1.9m)"] }, > "fields" : { > "\_ttl" : 108740 > } > }, { > "\_index" : "mortal", > "\_type" : "ghost", > "\_id" : "5", > "\_version" : 1, > "\_score" : 1.0, "\_source" : { "cn" : "Jack Skellington" , "text" : [ > "Lifetime set to default (1.9m)" ] }, > "fields" : { > "\_ttl" : 108740 > } > }, { > "\_index" : "mortal", > "\_type" : "ghost", > "\_id" : "8", > "\_version" : 1, > "\_score" : 1.0, "\_source" : { "cn" : "Space Ghost" , "text" : [ > "Gone in 4 minutes" ] }, > "fields" : { > "\_ttl" : 234740 > } > }, { > "\_index" : "mortal", > "\_type" : "ghost", > "\_id" : "9", > "\_version" : 1, > "\_score" : 1.0, "\_source" : { "cn" : "Boo Berry" , "text" : [ "Gone > in 5 minutes" ] }, > "fields" : { > "\_ttl" : 291740 > } > }, { > "\_index" : "mortal", > "\_type" : "elf", > "\_id" : "1", > "\_version" : 1, > "\_score" : 1.0, "\_source" : { "cn" : "Celeborn" , "text" : [ "Lives > forever" ] } > }, { > "\_index" : "mortal", > "\_type" : "elf", > "\_id" : "2", > "\_version" : 1, > "\_score" : 1.0, "\_source" : { "cn" : "Galadriel" , "text" : [ "Lives > forever" ] } > }, { > "\_index" : "mortal", > "\_type" : "elf", > "\_id" : "3", > "\_version" : 1, > "\_score" : 1.0, _"\_source"_ : { "cn" : "Haldir of Lórien" , "text" > : ["Dies in the battle of Helm's Deep", "Gone in 3m"] }, > _"fields" : {_ > > - > > ``` > "_ttl" : 174740* > } > > ``` > > } ] > } > } > > You can perhaps see how I got confused in the beginning. I have to call setFields("\_ttl", > "\_source") even though _\_source_ comes back on its own while \*"\_ttl"\*comes back in the > _"fields"_ JSON object. Just enough to throw me off. But the newsgroups > are very friendly and helpful. -- 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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 2:43am UTC](https://discuss.elastic.co/t/ttl-question/11400/13 "2017-07-06T02:43:12Z")