Add `Pool` object for managing sessions (retries, reconnections, etc) #95

New issue

Open

opened 2025-01-03 01:19:42 +00:00 by guo1017138 · 2 comments

guo1017138 commented

2025-01-03 01:19:42 +00:00

(Migrated from github.com)

This is not an issue, but I suggest to enhance it for rainy day case.

Problem Description:

started a netconf client normally, make sure it works.
restart netconf server to simulate server restart / network issue.
clients won't work again.

Workaround:
I can detect it by the following code sample. But I need to detect several errors as following per my expierence(maybe not all, just what I found). If this lib can support autoconnect feature such like Rockwell AB PLC or just make returned error to be simple will be better.


func (c *Client) checkNetworkError(err error) {
	if err == nil {
		return
	}
	_, ok := err.(net.Error)
	if ok ||
		strings.Contains(err.Error(), "connection closed unexpectedly") ||
		strings.Contains(err.Error(), "EOF") ||
		strings.Contains(err.Error(), "existing message writer still open") {
		c.Logger.Error("network error, reconnecting...")
		err = c.reconnect()
		if err != nil {
			c.Logger.Errorf("reconnect failed: %v", err)
			return
		}
		c.Logger.Info("reconnect success")
	}
}

This is not an issue, but I suggest to enhance it for rainy day case. Problem Description: 1. started a netconf client normally, make sure it works. 2. restart netconf server to simulate server restart / network issue. 3. clients won't work again. Workaround: I can detect it by the following code sample. But I need to detect several errors as following per my expierence(maybe not all, just what I found). If this lib can support autoconnect feature such like [Rockwell AB PLC](github.com/danomagnum/gologix) or just make returned error to be simple will be better. ```golang func (c *Client) checkNetworkError(err error) { if err == nil { return } _, ok := err.(net.Error) if ok || strings.Contains(err.Error(), "connection closed unexpectedly") || strings.Contains(err.Error(), "EOF") || strings.Contains(err.Error(), "existing message writer still open") { c.Logger.Error("network error, reconnecting...") err = c.reconnect() if err != nil { c.Logger.Errorf("reconnect failed: %v", err) return } c.Logger.Info("reconnect success") } } ```

nemith commented

2025-01-04 00:51:29 +00:00

(Migrated from github.com)

I think both are needed. I've been meaning to clean up transport errors (and fail on any error from the transport).

I have been tossing around the idea of a higher order "pool" package which would handle not only reconnects when there are failures (or lazy connect) but also be able to handle multiple requests over multiple sockets up to some set value. This would be a good use case here (with maxConnection set to 1)

I think both are needed. I've been meaning to clean up transport errors (and fail on any error from the transport). I have been tossing around the idea of a higher order "pool" package which would handle not only reconnects when there are failures (or lazy connect) but also be able to handle multiple requests over multiple sockets up to some set value. This would be a good use case here (with maxConnection set to 1)

nemith commented

2025-12-30 01:59:13 +00:00

(Migrated from github.com)

There is a problem with autoreconnect. NETCONF is connection oriented. There are RPC calls like <lock> and <unlock> or <commit><confirmed/> that assume the connection itself to do the right things. Doing a reconnect between calls breaks this.

I do realize there are use cases like a notification receiver. This goes back to having a manager or a pool (need to noodle on this a bit).

Now if the network fails we need to return an error and not freeze. I am in the middle of a rewrite and I will add some tests around network disconnects so that the library consumer can reconnect.

There is a problem with autoreconnect. NETCONF is connection oriented. There are RPC calls like `<lock>` and `<unlock>` or `<commit><confirmed/>` that assume the connection itself to do the right things. Doing a reconnect between calls breaks this. I do realize there are use cases like a notification receiver. This goes back to having a manager or a pool (need to noodle on this a bit). Now if the network fails we need to return an error and not freeze. I am in the middle of a rewrite and I will add some tests around network disconnects so that the library consumer can reconnect.