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.

Sign up for GitHub

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

Jump to bottom

revamp log file writing #277

Closed
mattklein123 opened this issue Dec 7, 2016 · 3 comments
Closed

revamp log file writing #277

mattklein123 opened this issue Dec 7, 2016 · 3 comments
Labels
enhancement Feature requests. Not bugs or questions. help wanted Needs help!

Comments

@mattklein123
Copy link
Member

Started to think about this more after an internal bug report and produced this: #276

But then I realized this is all still broken across two axes:

  1. Hot restart (no super trivial fix)
  2. We allow the same file to be written by multiple FileImpl within the process (depending on configuration).

#2 is not that hard to fix, we could have the access log manager hand out an existing file if it's already created.

But #1 has no easy fix, and will become a big problem if we want to do inline compression. I think we need to stop doing the cross process writes for log files and move to a more traditional log file per process approach either by appending the PID or the hot restart epoch to the file in some way.
@mattklein123 mattklein123 self-assigned this Dec 7, 2016
@mattklein123
Copy link
Member Author

First pass: #276

@mattklein123 mattklein123 added the enhancement Feature requests. Not bugs or questions. label Dec 17, 2016
@mattklein123 mattklein123 removed the bug label Jan 24, 2017
@mattklein123 mattklein123 changed the title revamp log file writing revamp log file writing / gRPC logging Feb 25, 2017
@mattklein123
Copy link
Member Author

Let's also use this issue to track implementing a gRPC/proto logging format, logging adapters, etc.

@mattklein123 mattklein123 removed their assignment Mar 24, 2017
@mattklein123 mattklein123 changed the title revamp log file writing / gRPC logging revamp log file writing May 9, 2017
@mattklein123 mattklein123 added the help wanted Needs help! label Oct 28, 2017
rshriram pushed a commit to rshriram/envoy that referenced this issue Oct 30, 2018
@qiwzhang
add global context (envoyproxy#277)
00c0ffd 
* add global context

* Move certs and jwt_cache back.

* Update comment.
@mattklein123
Copy link
Member Author

Closing this as this has never been raised as a real issue by anyone. Can reopen later if needed.

PiotrSikora referenced this issue in istio/envoy Nov 1, 2019
@kyessenov @jplevyak
wasm: use bytes for filter state storage (#277)
3a5f311 
Signed-off-by: Kuat Yessenov <kuat@google.com>
lizan pushed a commit to lizan/envoy that referenced this issue Oct 30, 2020
@kyessenov
fix: record recovered local address (envoyproxy#13581) (envoyproxy#277)
4760a0f 
Signed-off-by: Kuat Yessenov <kuat@google.com>
jpsim pushed a commit that referenced this issue Nov 28, 2022
@rebello95 @jpsim
swift: expose URL components instead of URL type (#277)
25146fc 
As we bridge over the platform layers to talk to the C/C++ core, we'll need to be able to send headers such as `:method`/`:scheme`/`:authority`.

The `URL` type exposes optionals for these properties, which means we need to either handle them at initialization time or at the time when the request is executed by unwrapping them and throwing/failing.

In order to prevent throwing when deconstructing `URL` components, we are instead updating the interfaces to accept these 3 fields separately.

Signed-off-by: Michael Rebello <mrebello@lyft.com>
Signed-off-by: JP Simard <jp@jpsim.com>
jpsim pushed a commit that referenced this issue Nov 29, 2022
@rebello95 @jpsim
swift: expose URL components instead of URL type (#277)
e196a1f 
As we bridge over the platform layers to talk to the C/C++ core, we'll need to be able to send headers such as `:method`/`:scheme`/`:authority`.

The `URL` type exposes optionals for these properties, which means we need to either handle them at initialization time or at the time when the request is executed by unwrapping them and throwing/failing.

In order to prevent throwing when deconstructing `URL` components, we are instead updating the interfaces to accept these 3 fields separately.

Signed-off-by: Michael Rebello <mrebello@lyft.com>
Signed-off-by: JP Simard <jp@jpsim.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement Feature requests. Not bugs or questions. help wanted Needs help!
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@mattklein123