Issue 1:
Enabling configuring per bucket aggregation a threshold for the document counts on the buckets, so only buckets that contain more than n (defaults to 1) documents will be returned.

When n > 1, this may be only implementable in the reduce phase (because of the distributed nature of Elasticsearch), so there won't be any speed-up or slow-down compared to n == 1.

The n = 0 case is interesting because it could be a generalization of the "all_terms": true setting of terms facets[1] and the empty_bucets of the histogram aggregation

[1] http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-facets-terms-facet.html#_all_terms

Issue 2:
Elasticsearch version: "5.0.0-rc1"

Plugins installed: [ingest-geoip@5.0.0-rc1, ingest-user-agent@5.0.0-rc1, x-pack@5.0.0-rc1]

JVM version: OpenJDK "1.8.0_101"

OS version: Linux 4.4.11-23.53.amzn1.x86_64

Description of the problem including expected versus actual behavior:

We tried to set up a tribe node to connect to an existing ES cluster (which is working just fine) but the node failed to start and the following error debug messages appears whenever we try to start the node:

[2016-10-26T10:10:12,814][DEBUG][n.u.i.PlatformDependent0 ] java.nio.Buffer.address: unavailable

java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessDeclaredMembers")

...

[2016-10-26T10:10:12,942][DEBUG][n.u.NetUtil ] Failed to get SOMAXCONN from: /proc/sys/net/core/somaxconn

java.security.AccessControlException: access denied ("java.io.FilePermission" "/proc/sys/net/core/somaxconn" "read")

...

Exception: java.security.AccessControlException thrown from the UncaughtExceptionHandler in thread "main"

Exception: java.security.AccessControlException thrown from the UncaughtExceptionHandler in thread "Thread-2"

Not really sure if we missed anything, but it seems to be a permission issue so we've tried to run the ES tribe node as a root and also tried to reinstall the ES but we still bumped to the same error. There is no issue if we started the node as a normal data node as part of the cluster.

elasticsearch.yml

network.host: 0.0.0.0
http.port: 9200
transport.tcp.port: 9300
node.name: ${HOSTNAME}
discovery.zen.minimum_master_nodes: 2
bootstrap.memory_lock: true
indices.fielddata.cache.size: 50%
indices.queries.cache.size: 20%
xpack.security.audit.enabled: true
xpack.security.enabled: true
xpack.monitoring.enabled: true
xpack.watcher.enabled: true

xpack.security.authc.realms.file.type: file
xpack.security.authc.realms.file.order: 0
xpack.security.authc.realms.file.enabled: false
xpack.security.authc.realms.native1.type: native
xpack.security.authc.realms.native1.order: 1
xpack.security.authc.realms.native1.enabled: true
xpack.security.authc.realms.ldap1.type: ldap
xpack.security.authc.realms.ldap1.order: 2
xpack.security.authc.realms.ldap1.enabled: true
xpack.security.authc.realms.ldap1.url: ldap://ldap.dcma.epicon.com:389
xpack.security.authc.realms.ldap1.bind_dn: cn=ldapsearch,ou=users,o=local,dc=dcmaproxy,dc=epicon,dc=com
xpack.security.authc.realms.ldap1.bind_password: <XXX>
xpack.security.authc.realms.ldap1.user_search.base_dn: o=external,dc=dcmaproxy,dc=epicon,dc=com
xpack.security.authc.realms.ldap1.user_search.attribute: sAMAcountName
xpack.security.authc.realms.ldap1.group_search.base_dn: o=external,dc=dcmaproxy,dc=epicon,dc=com
xpack.security.authc.realms.ldap1.files.role_mapping: /etc/elasticsearch/x-pack/role_mapping.yml
xpack.security.authc.realms.ldap1.unmapped_groups_as_roles: false

node.master: false
node.data: false
tribe.on_conflict: prefer_dc
tribe.dc.cluster.name: epicon_es_dc
tribe.dc.network.host: 192.167.168.95
tribe.dc.discovery.zen.ping.unicast.hosts: ["192.167.168.91", "192.167.168.92", "192.167.168.93", "192.167.168.95

Steps to reproduce:

Set the ES node as a tribe node as configured above

Enable debug level logging and start the tribe node

Check log

Provide logs (if relevant):

elasticsearch.txt