TTL question

Elastic Stack Elasticsearch
1

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.
For more options, visit https://groups.google.com/groups/opt_out.

2

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.
For more options, visit https://groups.google.com/groups/opt_out.

3

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 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.
For more options, visit https://groups.google.com/groups/opt_out.

4

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 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.
For more options, visit https://groups.google.com/groups/opt_out.

5

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
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 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.
For more options, visit https://groups.google.com/groups/opt_out.

6

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.
For more options, visit https://groups.google.com/groups/opt_out.

7

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. :wink:

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.
For more options, visit https://groups.google.com/groups/opt_out.

8

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. :wink:

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.
For more options, visit https://groups.google.com/groups/opt_out.

9

  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.
For more options, visit https://groups.google.com/groups/opt_out.

10

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.
For more options, visit https://groups.google.com/groups/opt_out.

11

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' -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.
For more options, visit https://groups.google.com/groups/opt_out.

12

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' -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.
For more options, visit https://groups.google.com/groups/opt_out.