OK, HTTP module is NOT enabled. This is good practice for data nodes. But
the second sentence makes me puzzled. So the point is that it makes sense
for data nodes to have HTTP disabled because non data nodes (which receive
HTTP requests) can talk to them via transport (Netty as of now). Correct? Or
is there any other message? (It is probably just wording and me not being a
native speaker but the way how the second sentence begins "This make
sense..." seems to be referring to http.enabled = false in the first
sentence.)
Yea, its a bit misleading. The "HTTP hit" happens once, when a node
receives an http request, and that request needs to be redirected, or
distributed to other nodes, it will use the transport layer (tcp/netty) to
do that.
What I was trying to example is that you can create very simple load
balancers by simply firing up elasticsearch nodes that are configured to
hold no data. And, if all HTTP traffic will go to the elasticsearch load
balancers, then you there is no need to enable HTTP on the rest of the nodes
that hold the data.
OK, HTTP module is NOT enabled. This is good practice for data nodes. But
the second sentence makes me puzzled. So the point is that it makes sense
for data nodes to have HTTP disabled because non data nodes (which receive
HTTP requests) can talk to them via transport (Netty as of now). Correct? Or
is there any other message? (It is probably just wording and me not being a
native speaker but the way how the second sentence begins "This make
sense..." seems to be referring to http.enabled = false in the first
sentence.)
Yea, its a bit misleading. The "HTTP hit" happens once, when a node
receives an http request, and that request needs to be redirected, or
distributed to other nodes, it will use the transport layer (tcp/netty) to
do that.
What I was trying to example is that you can create very simple load
balancers by simply firing up elasticsearch nodes that are configured to
hold no data. And, if all HTTP traffic will go to the elasticsearch load
balancers, then you there is no need to enable HTTP on the rest of the nodes
that hold the data.
OK, HTTP module is NOT enabled. This is good practice for data nodes. But
the second sentence makes me puzzled. So the point is that it makes sense
for data nodes to have HTTP disabled because non data nodes (which receive
HTTP requests) can talk to them via transport (Netty as of now). Correct? Or
is there any other message? (It is probably just wording and me not being a
native speaker but the way how the second sentence begins "This make
sense..." seems to be referring to http.enabled = false in the first
sentence.)
I am looking into the code and I see that for both transport and discovery
modules there are also local counterparts of netty and jgroups
implementations respectively. What are they used for? (Are they used
internally on a data node when that node is running also HTTP module and
Discovery module?)
Yea, its a bit misleading. The "HTTP hit" happens once, when a node
receives an http request, and that request needs to be redirected, or
distributed to other nodes, it will use the transport layer (tcp/netty) to
do that.
What I was trying to example is that you can create very simple load
balancers by simply firing up elasticsearch nodes that are configured to
hold no data. And, if all HTTP traffic will go to the elasticsearch load
balancers, then you there is no need to enable HTTP on the rest of the nodes
that hold the data.
OK, HTTP module is NOT enabled. This is good practice for data nodes. But
the second sentence makes me puzzled. So the point is that it makes sense
for data nodes to have HTTP disabled because non data nodes (which receive
HTTP requests) can talk to them via transport (Netty as of now). Correct? Or
is there any other message? (It is probably just wording and me not being a
native speaker but the way how the second sentence begins "This make
sense..." seems to be referring to http.enabled = false in the first
sentence.)
They are part of the upcoming 0.5 full support for Java APIs. Part of the
story when working with Java is starting elasticsearch in disconnected
embedded mode. This comes very handy for writing tests. The local discovery
and local transport support that (an entire Server can be started with
node.local set to true and all things that can be local will be, in our
case, discovery and transport).
The local implementations are JVM level (well, actually class loader level),
which means that if you start two nodes in the same JVM they will discovery
each other. This again can come very handy when testing.
I am looking into the code and I see that for both transport and discovery
modules there are also local counterparts of netty and jgroups
implementations respectively. What are they used for? (Are they used
internally on a data node when that node is running also HTTP module and
Discovery module?)
Yea, its a bit misleading. The "HTTP hit" happens once, when a node
receives an http request, and that request needs to be redirected, or
distributed to other nodes, it will use the transport layer (tcp/netty) to
do that.
What I was trying to example is that you can create very simple load
balancers by simply firing up elasticsearch nodes that are configured to
hold no data. And, if all HTTP traffic will go to the elasticsearch load
balancers, then you there is no need to enable HTTP on the rest of the nodes
that hold the data.
OK, HTTP module is NOT enabled. This is good practice for data nodes.
But the second sentence makes me puzzled. So the point is that it makes
sense for data nodes to have HTTP disabled because non data nodes (which
receive HTTP requests) can talk to them via transport (Netty as of now).
Correct? Or is there any other message? (It is probably just wording and me
not being a native speaker but the way how the second sentence begins "This
make sense..." seems to be referring to http.enabled = false in the first
sentence.)
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.