You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pinot.apache.org by "Harnoor7 (via GitHub)" <gi...@apache.org> on 2025/01/07 17:35:47 UTC
[PR] Fixes Helix threads getting blocked edge case [pinot]
Harnoor7 opened a new pull request, #14771:
URL: https://github.com/apache/pinot/pull/14771
(no comment)
--
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: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
Re: [PR] Fixes Helix threads getting blocked for Realtime Tables [pinot]
Posted by "KKcorps (via GitHub)" <gi...@apache.org>.
KKcorps commented on code in PR #14771:
URL: https://github.com/apache/pinot/pull/14771#discussion_r1912897224
##########
pinot-core/src/main/java/org/apache/pinot/core/data/manager/realtime/RealtimeSegmentDataManager.java:
##########
@@ -1619,7 +1620,17 @@ public RealtimeSegmentDataManager(SegmentZKMetadata segmentZKMetadata, TableConf
// Acquire semaphore to create stream consumers
try {
- _partitionGroupConsumerSemaphore.acquire();
+ while (!_partitionGroupConsumerSemaphore.tryAcquire(5, TimeUnit.MINUTES)) {
+ // reload segment metadata to get latest status
+ segmentZKMetadata = _realtimeTableDataManager.fetchZKMetadata(_segmentNameStr);
+
+ if (segmentZKMetadata.getStatus() == CommonConstants.Segment.Realtime.Status.DONE) {
Review Comment:
+ also cover the case where segment status is UPLOADED
##########
pinot-core/src/main/java/org/apache/pinot/core/data/manager/realtime/RealtimeSegmentDataManager.java:
##########
@@ -1619,7 +1620,17 @@ public RealtimeSegmentDataManager(SegmentZKMetadata segmentZKMetadata, TableConf
// Acquire semaphore to create stream consumers
try {
- _partitionGroupConsumerSemaphore.acquire();
+ while (!_partitionGroupConsumerSemaphore.tryAcquire(5, TimeUnit.MINUTES)) {
+ // reload segment metadata to get latest status
+ segmentZKMetadata = _realtimeTableDataManager.fetchZKMetadata(_segmentNameStr);
+
+ if (segmentZKMetadata.getStatus() == CommonConstants.Segment.Realtime.Status.DONE) {
Review Comment:
Also cover the case where segment status is UPLOADED
--
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: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
Re: [PR] Fixes Helix threads getting blocked for Realtime Tables [pinot]
Posted by "siddharthteotia (via GitHub)" <gi...@apache.org>.
siddharthteotia commented on code in PR #14771:
URL: https://github.com/apache/pinot/pull/14771#discussion_r1916065480
##########
pinot-core/src/main/java/org/apache/pinot/core/data/manager/realtime/RealtimeSegmentDataManager.java:
##########
@@ -1619,7 +1620,17 @@ public RealtimeSegmentDataManager(SegmentZKMetadata segmentZKMetadata, TableConf
// Acquire semaphore to create stream consumers
try {
- _partitionGroupConsumerSemaphore.acquire();
+ while (!_partitionGroupConsumerSemaphore.tryAcquire(5, TimeUnit.MINUTES)) {
Review Comment:
What is the behavior we are expecting if timed acquisition fails ?
--
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: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
Re: [PR] Fixes Helix threads getting blocked for Realtime Tables [pinot]
Posted by "KKcorps (via GitHub)" <gi...@apache.org>.
KKcorps commented on code in PR #14771:
URL: https://github.com/apache/pinot/pull/14771#discussion_r1907596966
##########
pinot-core/src/main/java/org/apache/pinot/core/data/manager/realtime/RealtimeSegmentDataManager.java:
##########
@@ -1619,7 +1620,17 @@ public RealtimeSegmentDataManager(SegmentZKMetadata segmentZKMetadata, TableConf
// Acquire semaphore to create stream consumers
try {
- _partitionGroupConsumerSemaphore.acquire();
+ while (!_partitionGroupConsumerSemaphore.tryAcquire(5, TimeUnit.MINUTES)) {
+ // reload segment metadata to get latest status
+ segmentZKMetadata = _realtimeTableDataManager.fetchZKMetadata(_segmentNameStr);
+
+ if (segmentZKMetadata.getStatus() != CommonConstants.Segment.Realtime.Status.IN_PROGRESS) {
Review Comment:
change this check to == Status.DONE
reason being in pauseless, the segment can be in a new COMMITTING state where it still doesn't have download url.
--
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: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
Re: [PR] Fixes Helix threads getting blocked for Realtime Tables [pinot]
Posted by "siddharthteotia (via GitHub)" <gi...@apache.org>.
siddharthteotia commented on PR #14771:
URL: https://github.com/apache/pinot/pull/14771#issuecomment-2591843617
> It's better to do timed acquire on semaphore than the current approach to avoid extremely slow ingestion.
Can you describe the behavior before and after from both correctness and performance improvement point of view?
--
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: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
Re: [PR] ~Fixes Helix threads getting blocked for Realtime Tables~ [pinot]
Posted by "noob-se7en (via GitHub)" <gi...@apache.org>.
noob-se7en closed pull request #14771: ~Fixes Helix threads getting blocked for Realtime Tables~
URL: https://github.com/apache/pinot/pull/14771
--
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: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
Re: [PR] Fixes Helix threads getting blocked for Realtime Tables [pinot]
Posted by "siddharthteotia (via GitHub)" <gi...@apache.org>.
siddharthteotia commented on PR #14771:
URL: https://github.com/apache/pinot/pull/14771#issuecomment-2591840210
Have we tested this fix on the situation you were observing in your (PROD ??) environment?
Did we do any kind of CPU profiling or thread dump analysis to root cause this ?
> Do you see any disadvantage of current approach.
From the analysis, it is not clear if we are 100% sure of the root-cause. It seems to me we are fixing a symptom and not the root-cause
--
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: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
Re: [PR] Fixes Helix threads getting blocked for Realtime Tables [pinot]
Posted by "Harnoor7 (via GitHub)" <gi...@apache.org>.
Harnoor7 commented on PR #14771:
URL: https://github.com/apache/pinot/pull/14771#issuecomment-2576806063
@Jackie-Jiang the consuming threads will be interrupted during `consuming -> online` transition and catch up to final offset will be done by the Helix Thread (HelixTaskExecutor-message_handle_thread).
--
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: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
Re: [PR] Fixes Helix threads getting blocked for Realtime Tables [pinot]
Posted by "9aman (via GitHub)" <gi...@apache.org>.
9aman commented on PR #14771:
URL: https://github.com/apache/pinot/pull/14771#issuecomment-2577313170
> > I'm curious about why the lock is not released. Slower consumer shouldn't cause lock to be held. That is the core to this problem
>
> Yes, I understand the core of the problem is that the semaphore is acquired for too long by the consumers and we should focus on that problem. There has been 2 incidents where the blame has been put on partial upserts. For Instance:
>
> 1. A table with partial upserts enabled resulted in all helix threads being blocked.
> 2. A server took 16 hours to load consuming segment for table which had partial upsert enabled.
>
> What I am trying to address here is that we should not run into situation where slow consuming segments block entire ingestion. For example - If we have `K` Kafka partitions, `K` helix threads acquiring the semaphore (catching up to offset) should not stop downloading of other segments for same table OR consumption of segments for diff tables.
The cathcup is allowed only for 30 seconds post which the segment is downloaded. Correct me if I am wrong.
--
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: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
Re: [PR] Fixes Helix threads getting blocked for Realtime Tables [pinot]
Posted by "Jackie-Jiang (via GitHub)" <gi...@apache.org>.
Jackie-Jiang commented on PR #14771:
URL: https://github.com/apache/pinot/pull/14771#issuecomment-2581840361
This PR can be used as a workaround. As @9aman pointed out, the catch up should take only 30 seconds. Maybe there is a bug which prevents the lock to be released when the consumption is slow.
--
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: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
Re: [PR] Fixes Helix threads getting blocked for Realtime Tables [pinot]
Posted by "Jackie-Jiang (via GitHub)" <gi...@apache.org>.
Jackie-Jiang commented on code in PR #14771:
URL: https://github.com/apache/pinot/pull/14771#discussion_r1909866607
##########
pinot-core/src/main/java/org/apache/pinot/core/data/manager/realtime/RealtimeSegmentDataManager.java:
##########
@@ -1619,7 +1620,17 @@ public RealtimeSegmentDataManager(SegmentZKMetadata segmentZKMetadata, TableConf
// Acquire semaphore to create stream consumers
try {
- _partitionGroupConsumerSemaphore.acquire();
+ while (!_partitionGroupConsumerSemaphore.tryAcquire(5, TimeUnit.MINUTES)) {
Review Comment:
Since we are doing a timed acquire, let's also log a warning if it cannot get the lock, and also log the wait time so far
##########
pinot-core/src/main/java/org/apache/pinot/core/data/manager/realtime/RealtimeSegmentDataManager.java:
##########
@@ -1619,7 +1620,17 @@ public RealtimeSegmentDataManager(SegmentZKMetadata segmentZKMetadata, TableConf
// Acquire semaphore to create stream consumers
try {
- _partitionGroupConsumerSemaphore.acquire();
+ while (!_partitionGroupConsumerSemaphore.tryAcquire(5, TimeUnit.MINUTES)) {
+ // reload segment metadata to get latest status
+ segmentZKMetadata = _realtimeTableDataManager.fetchZKMetadata(_segmentNameStr);
+
+ if (segmentZKMetadata.getStatus() == CommonConstants.Segment.Realtime.Status.DONE) {
Review Comment:
We want to first check if `segmentZKMetadata != null`. In corner cases, latest consuming segment might be deleted, and it can be `null`
--
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: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
Re: [PR] ~Fixes Helix threads getting blocked for Realtime Tables~ [pinot]
Posted by "noob-se7en (via GitHub)" <gi...@apache.org>.
noob-se7en commented on PR #14771:
URL: https://github.com/apache/pinot/pull/14771#issuecomment-2705581001
Closing this as I the description created some confusion and discussion is on wrong subject.
--
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: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
Re: [PR] Fixes Helix threads getting blocked for Realtime Tables [pinot]
Posted by "mcvsubbu (via GitHub)" <gi...@apache.org>.
mcvsubbu commented on PR #14771:
URL: https://github.com/apache/pinot/pull/14771#issuecomment-2623404879
> > The cathcup is allowed only for 30 seconds post which the segment is downloaded. Correct me if I am wrong. How is that blocking everything ?
>
> Yes, correct but these threads are still blocking the remaining threads right (30s condition is checked after indexing each message batch)? Do you see any disadvantage of current approach. It's better to do timed acquire on semaphore than the current approach to avoid extremely slow ingestion.
Do you really need the catchup option? I was even considering disabling that altogether. It is OK if the faster segments build and upload new segments and the slower ones simply download the finalized segments. I think we should put the entire catchup logic under a config.
--
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: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
Re: [PR] Fixes Helix threads getting blocked for Realtime Tables [pinot]
Posted by "Harnoor7 (via GitHub)" <gi...@apache.org>.
Harnoor7 commented on PR #14771:
URL: https://github.com/apache/pinot/pull/14771#issuecomment-2577062850
> I'm curious about why the lock is not released. Slower consumer shouldn't cause lock to be held. That is the core to this problem
Yes, I understand the core of the problem is that the semaphore is acquired for too long by the consumers and we should focus on that problem. There has been 2 incidents where the blame has been put on partial upserts.
For Instance:
1. A table with partial upserts enabled resulted in all helix threads being blocked.
2. A server took 16 hours to load consuming segment for table which had partial upsert enabled.
What I am trying to address here is that we should not run into situation where slow consuming segments block entire ingestion. For example - If we have `K` Kafka partitions, `K` helix threads acquiring the semaphore (catching up to offset) should not stop downloading of other segments for same table OR consumption of segments for diff tables.
--
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: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
Re: [PR] Fixes Helix threads getting blocked for Realtime Tables [pinot]
Posted by "codecov-commenter (via GitHub)" <gi...@apache.org>.
codecov-commenter commented on PR #14771:
URL: https://github.com/apache/pinot/pull/14771#issuecomment-2576037940
## [Codecov](https://app.codecov.io/gh/apache/pinot/pull/14771?dropdown=coverage&src=pr&el=h1&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) Report
Attention: Patch coverage is `0%` with `12 lines` in your changes missing coverage. Please review.
> Project coverage is 63.84%. Comparing base [(`59551e4`)](https://app.codecov.io/gh/apache/pinot/commit/59551e45224f1535c4863fd577622b37366ccc97?dropdown=coverage&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) to head [(`90444bb`)](https://app.codecov.io/gh/apache/pinot/commit/90444bb87b989b56defd64981522e504bc77cd67?dropdown=coverage&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache).
> Report is 1547 commits behind head on master.
| [Files with missing lines](https://app.codecov.io/gh/apache/pinot/pull/14771?dropdown=coverage&src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | Patch % | Lines |
|---|---|---|
| [...a/manager/realtime/RealtimeSegmentDataManager.java](https://app.codecov.io/gh/apache/pinot/pull/14771?src=pr&el=tree&filepath=pinot-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fpinot%2Fcore%2Fdata%2Fmanager%2Frealtime%2FRealtimeSegmentDataManager.java&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache#diff-cGlub3QtY29yZS9zcmMvbWFpbi9qYXZhL29yZy9hcGFjaGUvcGlub3QvY29yZS9kYXRhL21hbmFnZXIvcmVhbHRpbWUvUmVhbHRpbWVTZWdtZW50RGF0YU1hbmFnZXIuamF2YQ==) | 0.00% | [4 Missing and 1 partial :warning: ](https://app.codecov.io/gh/apache/pinot/pull/14771?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) |
| [...ata/manager/realtime/RealtimeTableDataManager.java](https://app.codecov.io/gh/apache/pinot/pull/14771?src=pr&el=tree&filepath=pinot-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fpinot%2Fcore%2Fdata%2Fmanager%2Frealtime%2FRealtimeTableDataManager.java&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache#diff-cGlub3QtY29yZS9zcmMvbWFpbi9qYXZhL29yZy9hcGFjaGUvcGlub3QvY29yZS9kYXRhL21hbmFnZXIvcmVhbHRpbWUvUmVhbHRpbWVUYWJsZURhdGFNYW5hZ2VyLmphdmE=) | 0.00% | [5 Missing :warning: ](https://app.codecov.io/gh/apache/pinot/pull/14771?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) |
| [...anager/realtime/SegmentAlreadyExistsException.java](https://app.codecov.io/gh/apache/pinot/pull/14771?src=pr&el=tree&filepath=pinot-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fpinot%2Fcore%2Fdata%2Fmanager%2Frealtime%2FSegmentAlreadyExistsException.java&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache#diff-cGlub3QtY29yZS9zcmMvbWFpbi9qYXZhL29yZy9hcGFjaGUvcGlub3QvY29yZS9kYXRhL21hbmFnZXIvcmVhbHRpbWUvU2VnbWVudEFscmVhZHlFeGlzdHNFeGNlcHRpb24uamF2YQ==) | 0.00% | [2 Missing :warning: ](https://app.codecov.io/gh/apache/pinot/pull/14771?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) |
<details><summary>Additional details and impacted files</summary>
```diff
@@ Coverage Diff @@
## master #14771 +/- ##
============================================
+ Coverage 61.75% 63.84% +2.09%
- Complexity 207 1607 +1400
============================================
Files 2436 2705 +269
Lines 133233 150935 +17702
Branches 20636 23320 +2684
============================================
+ Hits 82274 96369 +14095
- Misses 44911 47351 +2440
- Partials 6048 7215 +1167
```
| [Flag](https://app.codecov.io/gh/apache/pinot/pull/14771/flags?src=pr&el=flags&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | Coverage Δ | |
|---|---|---|
| [custom-integration1](https://app.codecov.io/gh/apache/pinot/pull/14771/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `100.00% <ø> (+99.99%)` | :arrow_up: |
| [integration](https://app.codecov.io/gh/apache/pinot/pull/14771/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `100.00% <ø> (+99.99%)` | :arrow_up: |
| [integration1](https://app.codecov.io/gh/apache/pinot/pull/14771/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `100.00% <ø> (+99.99%)` | :arrow_up: |
| [integration2](https://app.codecov.io/gh/apache/pinot/pull/14771/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `0.00% <ø> (ø)` | |
| [java-11](https://app.codecov.io/gh/apache/pinot/pull/14771/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `63.81% <0.00%> (+2.10%)` | :arrow_up: |
| [java-21](https://app.codecov.io/gh/apache/pinot/pull/14771/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `63.74% <0.00%> (+2.11%)` | :arrow_up: |
| [skip-bytebuffers-false](https://app.codecov.io/gh/apache/pinot/pull/14771/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `63.83% <0.00%> (+2.08%)` | :arrow_up: |
| [skip-bytebuffers-true](https://app.codecov.io/gh/apache/pinot/pull/14771/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `63.72% <0.00%> (+36.00%)` | :arrow_up: |
| [temurin](https://app.codecov.io/gh/apache/pinot/pull/14771/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `63.84% <0.00%> (+2.09%)` | :arrow_up: |
| [unittests](https://app.codecov.io/gh/apache/pinot/pull/14771/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `63.84% <0.00%> (+2.09%)` | :arrow_up: |
| [unittests1](https://app.codecov.io/gh/apache/pinot/pull/14771/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `56.30% <0.00%> (+9.41%)` | :arrow_up: |
| [unittests2](https://app.codecov.io/gh/apache/pinot/pull/14771/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `34.11% <0.00%> (+6.38%)` | :arrow_up: |
Flags with carried forward coverage won't be shown. [Click here](https://docs.codecov.io/docs/carryforward-flags?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache#carryforward-flags-in-the-pull-request-comment) to find out more.
</details>
[:umbrella: View full report in Codecov by Sentry](https://app.codecov.io/gh/apache/pinot/pull/14771?dropdown=coverage&src=pr&el=continue&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache).
:loudspeaker: Have feedback on the report? [Share it here](https://about.codecov.io/codecov-pr-comment-feedback/?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache).
--
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: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
Re: [PR] Fixes Helix threads getting blocked for Realtime Tables [pinot]
Posted by "Jackie-Jiang (via GitHub)" <gi...@apache.org>.
Jackie-Jiang commented on PR #14771:
URL: https://github.com/apache/pinot/pull/14771#issuecomment-2576822790
I'm curious about why the lock is not released. Slower consumer shouldn't cause lock to be held. That is the core to this problem
--
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: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
Re: [PR] Fixes Helix threads getting blocked for Realtime Tables [pinot]
Posted by "Harnoor7 (via GitHub)" <gi...@apache.org>.
Harnoor7 commented on PR #14771:
URL: https://github.com/apache/pinot/pull/14771#issuecomment-2577704195
> The cathcup is allowed only for 30 seconds post which the segment is downloaded. Correct me if I am wrong. How is that blocking everything ?
Yes, correct but these threads are still blocking the remaining threads right (30s condition is checked after indexing each message batch)? Do you see any disadvantage of current approach. It's better to do timed acquire on semaphore than the current approach to avoid extremely slow ingestion.
--
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: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org