| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
commit_hash:91a2de31f763fca2eb5b8595deb369458d889731
|
| |
|
|
| |
commit_hash:0f92ee40eb5e4a80c59a5cbdcac895ff7acd22e9
|
| |
|
|
| |
commit_hash:ba8c42476d6274212745348071682042e780037f
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
## Motivation
Profiling the YT master Automaton thread showed TOriginAttributes::Capture (run on every non-OK TError) spending ~60% of its time in a getpid() syscall — uncached on glibc >= 2.25. NYT::GetCurrentThreadId() (gettid) feeds hot thread-affinity / log-manager checks on the same thread.
## Changes
- New library/cpp/yt/system/process_id.* with cached GetProcessId(); GetSystemThreadId() now caches the kernel tid in TLS. Both caches reset in the child after fork.
- Moved thread_name.{h,cpp} from misc to system.
- Removed GetCurrentProcessId/GetCurrentThreadId shims from yt/yt/core/misc/proc.{h,cpp}; migrated all callers to NYT::GetProcessId / NYT::GetSystemThreadId.
- TOriginAttributes::Capture uses the cached getters; recorded Tid is now the real kernel tid (matches perf/ps).
- Added microbenchmarks (library/cpp/yt/system/benchmarks, yt/yt/core/benchmarks/error.cpp).
## Microbenchmarks (release)
| | before | after |
|---|---|---|
| getpid | 101 ns | 0.33 ns |
| gettid | 102 ns | 1.64 ns |
| Capture | 161 ns | 50 ns |
| failed TError | 221 ns | 74 ns |
commit_hash:ee37ae57d61a5a2dd33daee935270f4bb93b7ff9
|
| |
|
|
|
| |
`YA_COVERAGE_DUMP_PROFILE_AND_EXIT` is not used anymore
commit_hash:c7158fb4e201d522e6e2c31c91fa9361af4bf50c
|
| |
|
|
| |
commit_hash:5cd17c6fa69e4f6a18eb72ebb05a874491ae8ac7
|
| |
|
|
|
| |
Add a templated GetEnvValueOrThrow<T> that parses the environment variable value via FromString, next to the existing std::string overload.
commit_hash:0421b0463c473c8c7f88c0b1619484e52b002897
|
| |
|
|
| |
commit_hash:1156b3325b874f25124c2e535b63ae714d348818
|
| |
|
|
| |
commit_hash:58bf07dcff4aac728a67e0607d2c3b49ad1feef1
|
| |
|
|
|
| |
Added the ability to explicitly specify parsing options.
commit_hash:1bd7947cfc298f0c3edc895a77c64f70504b78d5
|
| |
|
|
| |
commit_hash:0db96562c160786c274a724485357e45753113e0
|
| |
|
|
| |
commit_hash:cdddd6e34a004a2942a80c4f94bcc8f80481d93a
|
| |
|
|
|
|
|
|
|
|
|
| |
Fix typos in docstrings
---
Pull Request resolved: https://github.com/ytsaurus/ytsaurus/pull/1733
Co-authored-by: ilyaibraev <[email protected]>
commit_hash:33a12aeaeeaec2f93ef9f465a3d5cdff95b62757
|
| |
|
|
| |
commit_hash:1023e8e70ded788fb37e7af6e0fa6cb508011aea
|
| |
|
|
| |
commit_hash:e8b2304f773f981dd79203f68a204671954ee399
|
| |
|
|
| |
commit_hash:ca6efe06865fe9fc9ebfd5ca8bbd79c2acbb4ff3
|
| |
|
|
| |
commit_hash:87f1242f4d944457ae5f4d7f22860ffb516b5b97
|
| |
|
|
| |
commit_hash:dbf6bb806bcac71fd67d65ec209838e5f5133710
|
| |
|
|
| |
commit_hash:3edd8e05acaa66bfc742eb137f73474783c91bc3
|
| |
|
|
| |
commit_hash:699e7e9a27bcf1220bbe3e408349a36a50408644
|
| |
|
|
| |
commit_hash:521dab2ac8a1582612ccc7734797e8bab9180714
|
| |
|
|
| |
commit_hash:776cd37ba05fd4d206ebf47b2a3bb2323bb32c51
|
| |
|
|
| |
commit_hash:b9f1c87173a18fb59f8cf684191efd4436dd6012
|
| |
|
|
| |
commit_hash:de6fd3d7115c7d34934e129720805c6a096292a2
|
| |
|
|
| |
commit_hash:fff41cdbc1400a312067a6517c334440404c662b
|
| |
|
|
|
| |
added i64 test
commit_hash:3fb3508267ad1008232631863d5e08abf6d1a397
|
| |
|
|
| |
commit_hash:3466775b052bc8a85a2aa85e9605968e7a5ea025
|
| |
|
|
| |
commit_hash:76b3f7346347ae83a1170d7b629fcf3da217d877
|
| |
|
|
| |
commit_hash:7218aca25ba819156cd6a364f9bd4ef8598c49ef
|
| |
|
|
| |
commit_hash:d1f3eb787ea596657b87ba8a5af239a2ecc4c41f
|
| |
|
|
|
| |
add assign() method for better compatibility with std::vector
commit_hash:7a216f3a025414493f3e6dc676b5c203208e462b
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
### Как сейчас
1. zsh подгружает `~/.zfunc/_<command>`, выполняет его как тело функции `_<command>`.
2. Это тело состоит только из определения `_<command>() { ... }` и helper'ов — оно переопределяет `_<command>`, но не вызывает новое определение.
3. Тело завершилось, ни одного `compadd` не было — completion ничего не выдал.
При втором TAB вызывается уже переопределённый "настоящий" `_<command>` — и тогда дополнение работает.
\--
### Что сделал
Добавил вызов `_<command>` в конец скрипта, так что теперь вызов переопределнного `_<command>` происходит на первом `Tab`.
commit_hash:9f60240a3c3d85088101570156c8bde18bf0792a
|
| |
|
|
| |
commit_hash:2728816c79b29fccf31698e16733a0220fd3069e
|
| |
|
|
|
|
|
|
|
| |
* Changelog entry
Type: feature
Component: master
Drop indicies in multicell manager
commit_hash:692a550606183f6a8cb93425761911bbba09dceb
|
| |
|
|
| |
commit_hash:f6ee801a97df2025e38187340cd97552462d4f49
|
| |
|
|
| |
commit_hash:2aadc4d98214f07a82d4fc4b072183f3e638a0ad
|
| |
|
|
| |
commit_hash:dfb089f297aa855d5b17f3e73cc2d125a93e1170
|
| |
|
|
| |
commit_hash:5a11a7288f325d6fa0a9bec9a1ce0b7afa1f4984
|
| |
|
|
| |
commit_hash:65763e635b968147880f0e83cd4bd93c591453a9
|
| |
|
|
| |
commit_hash:995b22e2ac0acd0c05a4d9cb033033c863e32bd9
|
| |
|
|
| |
commit_hash:7e973890af2061e2a78b34d31c404f000375a88b
|
| |
|
|
| |
commit_hash:075da2320aef76c06611fc1f363508ed26ad1a78
|
| |
|
|
| |
commit_hash:946123c814d23e070516ef5f7d339cf6025547b6
|
| |
|
|
| |
commit_hash:a21fb954574aa503699e20da93fad863363d4adf
|
| |
|
|
| |
commit_hash:a68c6e6d84fdd6f57df4488325de919b99c21d79
|
| |
|
|
| |
commit_hash:cc1f5b9ecc05f6b098f1645ba338fc644c0bb53f
|
| |
|
|
| |
commit_hash:2d2808f61599fcfea314ad660585e984d50ffbb3
|
| |
|
|
| |
commit_hash:5e6c329f3fd9e1aa58d910dba02af63568e95294
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unified Agent: новый протокол стриминга и изменения в клиенте
Документ опирается на `library/cpp/unified_agent_client/proto/unified_agent.proto` и реализацию `TClientSession` в `client_impl.cpp`.
---
## 1. Новый протокол
**Legacy** — сессия без согласования версии: в ответе `Initialized` поле `protocol_version` отсутствует или равно **0**. Поведение соответствует старому контракту до появления опциональных полей согласования.
**Версионированный режим (v1 и выше)** — клиент объявляет максимально поддерживаемую версию (`accept_protocol_version`), агент возвращает **согласованную** версию `protocol_version` и опционально **opaque**-токен привязки сессии. Дальнейшие реконнекты с тем же `session_id` требуют передачи **доказательства** привязки (`session_binding_proof`), чтобы сервер мог отличить легитимное продолжение от подмены.
Семантика потока данных не меняется: после `Initialized` идут `DataBatch` / `Ack`, ретраи по `seq_no` и дедупликация на стороне агента при совпадении `session_id` и повторной отправке записей.
---
### 1.2. Новые поля
**Запрос `Request.Initialize`**
| Поле | Тип | Назначение |
|------|-----|------------|
| `accept_protocol_version` | `optional uint32` | Верхняя граница версии, которую клиент готов использовать (стиль HTTP Accept). **Не задано или 0** — клиент не предлагает новый протокол (legacy-only). |
| `session_binding_proof` | `bytes` | Доказательство привязки при реконнекте; используется, когда согласована версия **> 0** и у клиента есть токен от предыдущего `Initialized`. |
Поля `session_id`, `meta`, `shared_secret_key` — как раньше; `session_id` при реконнекте передаётся для дедупликации.
**Ответ `Response.Initialized`**
| Поле | Тип | Назначение |
|------|-----|------------|
| `protocol_version` | `optional uint32` | Согласованная версия: **min**(accept клиента, максимум сервера). **Не задано или 0** — сессия считается **legacy**. |
| `session_binding_token` | `bytes` | Непрозрачный токен: клиент обязан вернуть его в следующем `Initialize` как `session_binding_proof` при переподключении (для версий протокола **≥ 1**). |
Остальное без изменений: `session_id`, `last_seq_no`.
---
### 1.3. Процесс и логика выбора версии
1. Клиент задаёт **`MaxAcceptProtocolVersion`** (в коде: `SetMaxAcceptProtocolVersion`). Значение **0** означает: поле `accept_protocol_version` в `Initialize` **не отправляется** — только legacy.
2. Если `MaxAcceptProtocolVersion > 0`, в первом (и последующих) сообщении `Initialize` выставляется `accept_protocol_version = MaxAcceptProtocolVersion`.
3. Агент вычисляет согласованную версию как **min**(`accept_protocol_version`, собственный потолок поддерживаемых версий) и возвращает её в `Initialized.protocol_version`. Если клиент не прислал accept (legacy-only) или сервер отвечает **0** / не задаёт поле — на клиенте фиксируется **legacy** (`NegotiatedProtocol` сбрасывается).
4. При успешном `Initialized` с **`protocol_version > 0`** клиент сохраняет число версии в `NegotiatedProtocol` и копирует `session_binding_token` во внутреннее состояние для следующих коннектов.
#### Диаграмма обмена (Mermaid sequence)
Первое подключение с согласованием версии и привязкой:
```mermaid
sequenceDiagram
participant C as Клиент (TClientSession)
participant G as gRPC stream
participant A as Unified Agent
C->>G: открыть Session(stream Request / stream Response)
C->>A: Request.initialize<br/>accept_protocol_version = N (если N>0)<br/>session_id (опц.)<br/>meta, shared_secret_key, …
Note over A: min(N, server_max) → negotiated
A->>C: Response.initialized<br/>session_id<br/>last_seq_no<br/>protocol_version = negotiated<br/>session_binding_token (opaque)
C->>C: сохранить NegotiatedProtocol,<br/>SessionBindingToken, SessionId
loop Данные
C->>A: Request.data_batch (seq_no, payload, …)
A->>C: Response.ack (seq_no)
end
Note over C,A: обрыв стрима → реконнект
```
Реконнект при согласованной версии **> 0**:
```mermaid
sequenceDiagram
participant C as Клиент
participant A as Unified Agent
C->>A: Request.initialize<br/>session_id = сохранённый<br/>accept_protocol_version = N<br/>session_binding_proof = прежний token<br/>…
A->>C: Response.initialized<br/>session_id, last_seq_no,<br/>protocol_version, session_binding_token (может обновиться)
C->>A: Request.data_batch …
```
---
### 1.4. Восстановление сессии и обмен ключами
- **Идентификатор сессии:** `session_id` приходит от сервера в `Initialized` и дальше передаётся в `Initialize` при реконнекте — основа для дедупликации и продолжения с теми же `seq_no`.
- **Shared secret:** по-прежнему `shared_secret_key` в `Initialize` (если задан в параметрах клиента) — отдельный канал авторизации/проверки, не смешивается с биндингом стрима.
- **Привязка сессии (protocol v1+):** после первого успешного `Initialized` с `protocol_version > 0` клиент хранит `session_binding_token`. При следующем `PrepareInitializeRequest`, если есть `NegotiatedProtocol > 0` и непустой токен, в запрос кладётся `session_binding_proof` (содержимое токена). Так сервер связывает новый gRPC-стрим с прежней логической сессией.
- **Конфликт сессии:** при завершении gRPC-вызова с кодом **`ALREADY_EXISTS`** клиент **сбрасывает** `SessionId`, `NegotiatedProtocol` и `SessionBindingToken`, чтобы следующий коннект не повторял конфликтующий идентификатор и не слал устаревшее proof (см. `OnGrpcCallFinished` в `client_impl.cpp`).
---
### 1.5. Совместимость клиентов и серверов
| Клиент | Сервер | Результат |
|--------|--------|-----------|
| `MaxAcceptProtocolVersion = 0` | любой | Поле `accept_protocol_version` не отправляется; ожидается legacy-ответ (`protocol_version` 0 / отсутствует). Биндинг по токену не используется. |
| `MaxAcceptProtocolVersion > 0` | только legacy | Обычно `protocol_version` в ответе 0 или отсутствует — клиент остаётся в legacy для этой сессии. |
| `MaxAcceptProtocolVersion > 0` | поддерживает v1+ | Согласуется конкретное число (например 1); включаются `session_binding_token` / `session_binding_proof` на реконнектах. |
| Новый клиент | старый агент | Безопасный откат: нет обязательных новых полей в wire-format для legacy; сервер игнорирует неизвестные optional-поля (proto3). |
Важно: поведение «только новый протокол» для отдельных механизмов (например принудительная отмена стрима по неактивности) в клиенте завязано на **фактически согласованную** версию **`NegotiatedProtocol > 0`**, а не только на настройку `MaxAcceptProtocolVersion`.
---
## 2. Изменения в клиенте — исправления и защита от регрессий
Ниже — логика, связанная с новым протоколом и устойчивостью сессий (файл `client_impl.cpp`, заголовки `client.h` / `client_impl.h`).
1. **Согласование версии и биндинг** — `PrepareInitializeRequest` выставляет `accept_protocol_version` только при `MaxAcceptProtocolVersion > 0`; при наличии согласованной версии и токена добавляет `session_binding_proof`. `OnGrpcCallInitialized` выставляет `NegotiatedProtocol` и `SessionBindingToken` только если `protocol_version` задан и **> 0**, иначе очищает их (строгий legacy).
2. **Конфликт `ALREADY_EXISTS`** — при таком статусе завершения стрима сбрасываются `SessionId`, `NegotiatedProtocol` и `SessionBindingToken`, чтобы не зациклиться на неверной паре (session_id, proof) и не провоцировать повторные конфликты на стороне агента.
3. **Watchdog неактивности gRPC (`GrpcCallInactivityTimeout`)** — принудительное закрытие активного вызова (`BeginClose(true)`) и счётчик `GrpcCallsClosedByInactivity` выполняются **только** при `NegotiatedProtocol.Defined() && *NegotiatedProtocol > 0`. Для legacy и до первого успешного `Initialized` с ненулевой версией отмена по этому таймеру **не** выполняется; таймер перепланируется как раньше. Это устраняет нежелательное принудительное реконнект-поведение на транспортах, где ранее допускалось «молчание» без отмены (см. план по этому пути).
4. **Пост-fork дочерний процесс** — сброс `SessionId`, `NegotiatedProtocol`, `SessionBindingToken` вместе с очередями, чтобы дочерний процесс не унаследовал привязку чужой сессии.
Документация в публичном API: комментарий к `SetGrpcCallInactivityTimeout` в `client.h` описывает ограничение по согласованной версии протокола.
---
*При необходимости уточнения формулы `min(accept, server_max)` на стороне агента смотрите реализацию сервера в репозитории `logbroker/unified_agent` (обработка `Initialize` в gRPC-сессии).*
commit_hash:9d5ef1cdc0faf793b4f56bfd2bafa362d7995ac5
|
| |
|
|
| |
commit_hash:84610a30b17de408952f5c68dbc32b18b753b247
|