Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flush changes from 1.0-FTY-master into 1.0-FTY "stable" #24

Merged
merged 29 commits into from
Jun 17, 2019

Conversation

jimklimov
Copy link
Member

No description provided.

Aaron Sokoloski and others added 28 commits January 23, 2018 14:13
(trying again -- the tests pass for me.  I'm not sure why they failed
before -- perhaps they have spurious failures?).

If the server is restarted and a client is still connected, it may
have a few CONNECTION_PING messages queued up on the socket which the
server will receive when it is restarted.  This is fine at the moment,
but in the case where the client does not then send CONNECTION_OPEN,
the server will try to deregister the client, and since the address
was never set, it segfaults.

Maybe this is only something I see because I'm working on a python
client and it's not well-behaved or something, but the server
shouldn't crash regardless, because even with well-behaved clients
this could happen if the client shuts down just after the server is
restarted.

Solution: cleanly handle the case of the client address being null.
Add a regression test.

(cherry picked from commit 08aa5ae)
2 places -- zstr_sendx without final NULL argument, and failing to destroy mlm_proto.

(cherry picked from commit a774bec)
This will allow us to properly handle pending stream traffic for
disconnected clients.

(cherry picked from commit b5c0d7d)
The current code inserts a one second delay in the hope that any pending
stream traffic will be flushed before the client context is destroyed.
Under heavy load, this may not work and we end up with a use-after-free
in s_forward_stream_traffic(). Instead of relying on luck, do proper
reference counting on the client contexts.

(cherry picked from commit ee93e46)
Insert a delay longer than the settle period into the stream engine to
trigger the race condition.

(cherry picked from commit c4262ce)
Properly handle pending stream traffic after client disconnect
Problem : invalid command log misses the command itself
backport from upstream : client unique identifier is not shared
Zproject regen before 1.5.0 branching
Signed-off-by: Gerald Guillaume <[email protected]>
Signed-off-by: Gerald Guillaume <[email protected]>
Signed-off-by: Gerald Guillaume <[email protected]>
 [issues/217] mlm_client_set_consumer broke the stream when pattern is *
…ter"

Solution: snprintf() already truncates to "bufsize-1" (and adds \0)
if needed, per docs, so we do not need to reduce it more.

This change matches current upstream malamute sources.

Signed-off-by: Jim Klimov <[email protected]>
Problem: "snprintf_chk output truncated before the last format character"
@jimklimov jimklimov requested a review from jana-rapava April 29, 2019 07:56
jana-rapava
jana-rapava previously approved these changes Apr 29, 2019
@aquette
Copy link
Member

aquette commented May 10, 2019

@jimklimov could you plz confirm that this was discussed and tested (originating from) with Dgé? and thus is mergeable with no regression...

@jimklimov
Copy link
Member Author

The 1fbb2b5 commit (current state of upstream/1.0-FTY-master) is used since end of April, that is about snprintf(). The earlier fix for * stream pattern is merged and in place for master-branch builds since early March. The 1.0-FTY branch saves the known-stable state but is not directly used in builds, except (for weird-legacy reason) in the FTY dispatcher repo.

@jimklimov
Copy link
Member Author

As for breaking or not, per zeromq#217 discussion the issue was to be addressed in czmq (or further in regex engine) and so not pursued in upstream malamute.

I commented my thoughts on that issue now, though.

@perrettecl perrettecl self-requested a review June 17, 2019 14:58
@perrettecl
Copy link

@jimklimov and @aquette What should we do with this PR ?

@jimklimov
Copy link
Member Author

I think, if we have not yet seen definitive malamute-related regressions (with this PR state in master images for 2 months now) then it is good to merge.

@perrettecl
Copy link

Ok Thank I will validate and merger prior branching

@perrettecl perrettecl merged commit b9104a7 into 1.0-FTY Jun 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants