[ 
https://issues.apache.org/jira/browse/FLINK-17611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17107933#comment-17107933
 ] 

Tzu-Li (Gordon) Tai commented on FLINK-17611:
---------------------------------------------

[~igal] concerning the YAML spec format:

Does the {{unix://}} scheme convention also support endpoint paths?
Otherwise, I also see a {{http+unix://}} convention used by 
[requests-unixsocket|https://pypi.org/project/requests-unixsocket/] to specify 
both the socket file path and url when performing HTTP requests over UDS.

either way: I like that we use the scheme part of the endpoint URL to determine 
whether or not to talk via UDS, instead of an extra field in the YAML spec.
It seems like a known convention, and is more compact.

> Support unix domain sockets for sidecar communication in Stateful Functions
> ---------------------------------------------------------------------------
>
>                 Key: FLINK-17611
>                 URL: https://issues.apache.org/jira/browse/FLINK-17611
>             Project: Flink
>          Issue Type: New Feature
>          Components: Stateful Functions
>            Reporter: Francesco Guardiani
>            Assignee: Francesco Guardiani
>            Priority: Major
>              Labels: pull-request-available
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Hi all,
> I'm quite new to this project and I've started investigating its potential 
> usage in Kubernetes.
> I've found in past that using Unix Domain Sockets across several containers 
> in the same pod gives an interesting performance boost and drastically 
> reduces the overhead of going through the network stack. Given that 
> containers in a pod run in the same host, it's perfectly reasonable to let 
> them communicate through unix domain sockets.
> If you're interested in such feature, I'm more than willing to help 
> implementing that, given that I need a few pointers where to start from



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to