Small correction or clarification - two (or more) operators that are
connected by a stream that is neither THREAD_LOCAL or CONTAINER_LOCAL
pass data using a buffer server. Upstream operator (publisher) sends
data to the buffer server and buffer server sends data to downstream
operator(s) (subscribers). In the current implementation of the buffer
server there is no assumption that it resides in the same container as
the upstream operator, so the communication is implemented using network
library (Netlet). At the same time to avoid complications with fault
tolerance and high availability buffer server is always deployed into
the same container as the upstream operator and lifetime of the buffer
server is the same as the operator and a fault in the buffer server will
cause redeployment of the upstream operator and similarly a fault in the
upstream operator will cause automatic redeploy of the buffer server.
This leads to the first optimization that is already implemented in the
buffer server - communication from the publisher (upstream operator) to
the buffer server is going over local loopback (not an actual network
device, but a virtual adapter). We are still paying price to pass data
over multiple call stacks - from the publisher to the AbstractClient in
the Netlet (connected using CircluarBuffer) and from the Netlet to the
kernel TCP/IP stack (requires copying data from the JVM heap to direct
buffers) and back from TCP/IP stack to the Netlet and to the buffer server.
I filed APEX-259 to see how much gain we can get by further leveraging
the fact that the upstream operator resides in the same container as the
buffer server so data can be passed within the same process (instead of
IPC) with BlockingQueue being one of the most efficient in process
channel inside JVM.
Thank you,
Vlad
On 11/13/15 11:19, Isha Arkatkar wrote:
Hi all,
For APEX-259 (https://malhar.atlassian.net/browse/APEX-259), I am
exploring option of passing serialized tuples from publisher to buffer
server through a blocking queue.
Right now, publisher and buffer server reside within the same container,
however, communication between the two goes though sockets. We want to
check if we get any performance benefit by changing this communication to
queue-based one.
This is in exploration phase right now, but if we do see improvement, we
may want to provide it as a pluggable option.
Please let me know your thoughts!
Thanks,
Isha
