zeromq / gyre Goto Github PK

Hi,

Any plans of moving away from pebbe/zmq4 to a pure go zmq implementation?

go-zeromq/zmq4 seems to be pretty active and may have what you need

It'd be nice to get rid of the C dependencies 😬

I tried this package in combination with the C implementation (https://github.com/zeromq/zyre) and it does not seem to work together.
Gyre does not detect the enter, shout, whisper events from zyre, it does detect the exit message though.

The readme.md says it is a port of Zyre 2.0 but the Zyre link is not working and I don't seem to find the specification of Zyre 2.0 anywhere

Please don't expose any panic statements even if they are used internally. They can be captured with recover inside the library, but they are difficult (in this case, I actually can't seem to recover at all) to capture in clients of the library.

I have two applications running on the same network. When one calls Leave(), it causes the other app to panic. This may be a bug, but even if it isn't, the panic cannot be recovered:

panic: [136FF149F072A30744B54B23B831541C] message status isn't equal to peer status, 2 != 3

goroutine 8 [running]:
panic(0x7d5600, 0xc82021e6d0)
    /usr/local/go/src/runtime/panic.go:464 +0x3e6
github.com/zeromq/gyre.(*node).recvFromPeer(0xc8201a84b0, 0x7f7804729338, 0xc8201f4f00)
    /srv/go/src/github.com/zeromq/gyre/node.go:708 +0x9d2
github.com/zeromq/gyre.(*node).actor.func4(0x1, 0x0, 0x0)
    /srv/go/src/github.com/zeromq/gyre/node.go:842 +0x214
github.com/pebbe/zmq4.(*Reactor).Run(0xc820015b00, 0x989680, 0x0, 0x0)
    /srv/go/src/github.com/pebbe/zmq4/reactor.go:187 +0x870
github.com/zeromq/gyre.(*node).actor(0xc8201a84b0)
    /srv/go/src/github.com/zeromq/gyre/node.go:847 +0x312
created by github.com/zeromq/gyre.newGyre
    /srv/go/src/github.com/zeromq/gyre/gyre.go:94 +0x201

https://github.com/zeromq/gyre/blob/master/node.go#L702

https://github.com/zeromq/gyre/blob/master/node.go#L708

This really isn't an issue, but more of a question. Sorry if it is inappropriate here, I didn't know of a better place to ask.

Has anybody tried deploying something like your chat docker container in Kubernetes? I can run the chat example fine locally on my laptop. It also works fine in Kubernetes if I run multiple containers in a single pod. However, if I try to more each container into its own pod they no longer can discover each other.

Thanks for your time.

@see
pebbe/zmq4#184

Hi!
I'm currently thinking about to use this library in my project, but I see that the last commit was several month ago.
Will the library have an update and will it be maintain in the future?
I'm thinking about eventual security issues in the future which will have (or not) a patch.

Have a good day!

Best regards,

Majonsi

Gyre panics the full application on start() when run on interfaces without any addresses.

beacon/beacon.go:138 assumes that iface.Addrs() returns a non-empty array. If this is not true, the application panics.

hi there,
with the new golang version (and its built in url lib):

if !n.bound {
		_, n.port, err = bind(n.inbox, "tcp://*:*")
		if err != nil {
			return err
		}
		n.bound = true
	}

in node.go does not work anymore.

my workaround was to say:

if !n.bound {
		_, n.port, err = bind(n.inbox, "tcp://*:0")
		if err != nil {
			return err
		}
		n.bound = true
	}

in node.go

and:

	if p == "0" {
...

in node.go later. instead of if p == "*".

fyi.

Hi,

I tried a few things with this implementation, and found some panic.
Personally, from a library ... panic() are not so welcome ...
so, started to investigate and found the following scenario:

1. start my application, compiled with GYRE.
2. restart network (systemctl restart network).
   --> Application is stopped with a panic like "UDP impossible to send from XXX:xxx to YYY:yyy".
   (sorry, I don't have the exact message anymore, but very easy to reproduce).

After investigation, I came to remove one of the "panic" and all works well.
Pull request to follow soon (in case ...).

Saw also few other "panic()" in the code, but did not check if reached or not.
Anyway, hope this helps.