grpc stream invoke about layotto HOT 14 CLOSED

热升级的时候，连接会迁移，新进程一样可以在这个连接上把配置推送给应用，但问题是目前没有把应用订阅了哪些配置传递给新进程，这就导致新进程虽然拥有跟应用建立的连接，但没有向后端的配置中心重新订阅应用依赖的配置，导致后面就收不到配置变更的通知了，这里需要优化一下。

from layotto.

热升级的时候，连接会迁移，新进程一样可以在这个连接上把配置推送给应用，但问题是目前没有把应用订阅了哪些配置传递给新进程，这就导致新进程虽然拥有跟应用建立的连接，但没有向后端的配置中心重新订阅应用依赖的配置，导致后面就收不到配置变更的通知了，这里需要优化一下。

我想表达的是 grpc 的【流式调用】它是一个函数阻塞的，无法优雅的停掉

https://github.com/mosn/layotto/blob/main/pkg/grpc/api.go#L298

就算能通过一些手段停掉在老进程的这个goruntine， 然后在新的进程中重建这个goroutine并且拿到和老进程一样 http steam 也是一个问题。
我没想到一个好的方式来热重启这种stream的调用。

from layotto.

grpc的热升级只能发goaway了，新建连接。 这儿的流式估计是不好处理，如果流一直不断，老连接断了是会有损的哟。只能给每个stream请求设置一个超时了？

from layotto.

热升级的时候，连接会迁移，新进程一样可以在这个连接上把配置推送给应用，但问题是目前没有把应用订阅了哪些配置传递给新进程，这就导致新进程虽然拥有跟应用建立的连接，但没有向后端的配置中心重新订阅应用依赖的配置，导致后面就收不到配置变更的通知了，这里需要优化一下。

我想表达的是 grpc 的【流式调用】它是一个函数阻塞的，无法优雅的停掉

https://github.com/mosn/layotto/blob/main/pkg/grpc/api.go#L298

就算能通过一些手段停掉在老进程的这个goruntine， 然后在新的进程中重建这个goroutine并且拿到和老进程一样 http steam 也是一个问题。
我没想到一个好的方式来热重启这种stream的调用。

这里的gorountine应该是可以通过关闭mosn测的Listerner的accepts来关闭的.
https://github.com/mosn/mosn/blob/35ad451e012b4fde7bf4d9e76756054b34c2c1be/pkg/filter/network/grpc/factory.go#L225

from layotto.

热升级的时候，连接会迁移，新进程一样可以在这个连接上把配置推送给应用，但问题是目前没有把应用订阅了哪些配置传递给新进程，这就导致新进程虽然拥有跟应用建立的连接，但没有向后端的配置中心重新订阅应用依赖的配置，导致后面就收不到配置变更的通知了，这里需要优化一下。

我想表达的是 grpc 的【流式调用】它是一个函数阻塞的，无法优雅的停掉
https://github.com/mosn/layotto/blob/main/pkg/grpc/api.go#L298
就算能通过一些手段停掉在老进程的这个goruntine， 然后在新的进程中重建这个goroutine并且拿到和老进程一样 http steam 也是一个问题。
我没想到一个好的方式来热重启这种stream的调用。

这里的gorountine应该是可以通过关闭mosn测的Listerner的accepts来关闭的.
https://github.com/mosn/mosn/blob/35ad451e012b4fde7bf4d9e76756054b34c2c1be/pkg/filter/network/grpc/factory.go#L225

grpc 的gracefulstop 是不能主动关闭这些阻塞的goroutine把，

grpc-go server 的gracefulstop函数在这里：https://github.com/grpc/grpc-go/blob/4faa31f0a5809a5064ee128c9d855c0bedc1c783/server.go#L1752

grpc 的stop 是有损数据的，stop函数在这里：https://github.com/grpc/grpc-go/blob/4faa31f0a5809a5064ee128c9d855c0bedc1c783/server.go#L1706

from layotto.

grpc的conn是用的mosn的，listener也是mosn处理，这块 @nejisama 一起看看

from layotto.

stream 类型的热升级目前好像是有点问题，不过分析了一下，当前grpc对unary模式的热升级支持也是有一点问题的，可以看 mosn#1694

from layotto.

这个模拟出来的连接，在热迁移的时候好像也会被迁移，有点问题吧
https://github.com/mosn/layotto/blob/main/components/rpc/invoker/mosn/channel/xchannel.go#L38

from layotto.

这个模拟出来的连接，在热迁移的时候好像也会被迁移，有点问题吧
https://github.com/mosn/layotto/blob/main/components/rpc/invoker/mosn/channel/xchannel.go#L38

这里的模拟链接你指的是laytto和mosn之间的链接吗？还是说layotto本身的grpc的listener，如果是前者，本身laytto和mosn之间是没有真正的fd的，而是直接调用的mosn的函数，模拟数据传输。本身没fd的话是不会迁移的

from layotto.

这个模拟出来的连接，在热迁移的时候好像也会被迁移，有点问题吧
https://github.com/mosn/layotto/blob/main/components/rpc/invoker/mosn/channel/xchannel.go#L38

这里的模拟链接你指的是laytto和mosn之间的链接吗？还是说layotto本身的grpc的listener，如果是前者，本身laytto和mosn之间是没有真正的fd的，而是直接调用的mosn的函数，模拟数据传输。本身没fd的话是不会迁移的

func newXChannel(config ChannelConfig) (rpc.Channel, error) {
	proto := transport_protocol.GetProtocol(config.Protocol)
	if proto == nil {
		return nil, fmt.Errorf("protocol %s not found", proto)
	}
	if err := proto.Init(config.Ext); err != nil {
		return nil, err
	}

	m := &xChannel{proto: proto}
	m.pool = newConnPool(
		config.Size,
		func() (net.Conn, error) {
			local, remote := net.Pipe()
			localTcpConn := &fakeTcpConn{c: local}
			remoteTcpConn := &fakeTcpConn{c: remote} // 这个通过net.Pipe生成的connection
			if err := acceptFunc(remoteTcpConn, config.Listener); err != nil {
				return nil, err
			}
			return localTcpConn, nil
		},
		func() interface{} {
			return &xstate{respChans: map[uint64]chan api.XRespFrame{}}
		},
		m.onData,
	)

	return m, nil
}

这个通过net.Pipe生成的connection，确实没有FD，但是在mosn里面并没有做校验这是否是一个真实的连接而不是net.Pipe生产的。而是返回一个error

https://github.com/mosn/mosn/blob/master/pkg/network/transfer.go#L227

from layotto.

grpc支持不了连接迁移，直接走gracefulstop就行了，这儿应该没有问题。

from layotto.

https://github.com/mosn/mosn/blob/35ad451e012b4fde7bf4d9e76756054b34c2c1be/pkg/network/connection.go#L1020
直接设置false就行了，可以在 mosn/mosn#1694 这个issue统一处理掉

from layotto.

This issue has been automatically marked as stale because it has not had recent activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue or help wanted) or other activity occurs. Thank you for your contributions.

from layotto.

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as pinned, good first issue or help wanted. Thank you for your contributions.

from layotto.