Samrat002 commented on PR #28427:
URL: https://github.com/apache/flink/pull/28427#issuecomment-5326604999
> I think my last comment was not well formed. Now we have 3 places to solve
have metrics in s3 issue:
>
> * JM: here we do reordering
> * TM: Here we don't do reordering
> * `resolveMetricBridge` which does this dynamically and works for JM and
TM too
>
> This is kind of a brainsplit and I assume that we can drop JM reordering,
right?
Thanks @gaborgsomogyi, agreed—the split-brain behaviour existed because the
JM relied on startup reordering while the TM relied on late bridge attachment.
I have removed the JM-specific reordering and restored ClusterEntrypoint’s
original initialisation order. JM and TM now follow the same lifecycle: each
calls FileSystem.attachMetrics() when its process metric group becomes
available. The two runtime call sites only provide their respective metric
groups. The shared AwsSdkMetricBridge is now the single mechanism responsible
for handling initialisation order and cached S3 clients:
- If the S3 client is created first, it retains the stable bridge, which
begins publishing when setMetricGroup() is called later.
- If the metric group is attached first, the bridge receives the stored
group when the client is created.
Therefore, there are still separate JM and TM attachment points, but no
separate correctness strategies: both use the same order-independent bridge
behaviour.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
