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

update timeout middleware with warnings #218

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

aldas
Copy link
Contributor

@aldas aldas commented Jul 2, 2021

update timeout middleware with warnings and add example how to implement similar functionality in handler function

@aldas
Copy link
Contributor Author

aldas commented Jul 6, 2021

todo: probably should mention Nginx/Apache etc similar behavior and configuration settings

@@ -8,48 +8,62 @@ description = "Timeout middleware for Echo"

Timeout middleware is used to timeout at a long running operation within a predefined period.

When timeout occurs, and the client receives timeout response the handler keeps running its code and keeps using resources until it finishes and returns!
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for posting a comment too late. When I read this the first time I was not sure if it's true, so after a while playing around with the Timeout middleware a found a bug in it. Please see labstack/echo#1909
So, I think this should say that the handler must handle the Request Context properly in order to finish when the middleware timeouts.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no, only "reasonable" usecase for timeout middleware is to let handler execute until it normally finishes/exists regardless what happens with coroutine serving request. If this usecase is not needed - then timeout middleware is not needed. you could just create new context with timeout and be fine.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"reasonable" i.e. if client disconnects prematurely the db transaction would still get finished and commited.

if we start cancelling contexts it would mean that conn.ExecContext(ctx, query, args) would get cancelled and work would not get commited.

Copy link
Contributor Author

@aldas aldas Jul 6, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I should probably indicate that also in example that doBusinessLogic takes in will get deadlined.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think timeout has 2 properties that user may seek/need:

  • to get response before long-running handler actually finishes (for them even getting http.StatusServiceUnavailable better than nothing)
  • to let handler finish work regardless what happens to the client (for them getting unfinished work commited is essential)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, for me the timeout middleware was to ensure that your handler do the work you want in a particular time period, and if that isn't true you get a response that indicates that. And for that reason all the work should be stop. But your descriptions are more like a middleware to do async work, and of course you are right, if that is the case the work must continue until it is finished. Maybe we need to decide which of this two behaviors will be supported by this middleware an rename it to clarify our intention if it is needed.

}
```

## Alternatively handle timeouts in handlers
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm sure I'm missing something, because for me this is what the Timeout middleware is actually doing. Could you please help me to understand why this is better vs using the Timeout middleware?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my opinion handling work in background is not webserver responsibility and should be implemented explicitly in business domain (i.e. by developer). This ensures that people will not set e.Use(middleware.Timeout()) mindlessly without thinking what and why they actually do it.

// in different coroutine that should not access echo.Context and response writer

log.Printf("uid: %v\n", UID)
//res, err := slowDatabaseCon.ExecContext(ctx, query, args)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove this comment

Copy link
Contributor Author

@aldas aldas Jul 6, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll add note here. Using methods with contexts has maybe sideeffects that are not wanted - i.e. when timeout we set to request is reached, ctx will be cancelled and therefore methods with contexts could prematurely return

return err
}
}
return c.NoContent(http.StatusAccepted)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I got it correctly, this is returning a 202 even when doBusinessLogic finished. At this point the code should return 200 instead.

@aldas
Copy link
Contributor Author

aldas commented Jul 8, 2021

note to self: probably should add a note that order of middlewares is important. ala if timeout was added before logger. then logger middlewares logs response info for already served requests. Or what will happen if handler is websocket?

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.

None yet

2 participants