[jira] [Updated] (HBASE-28272) After triggering a Major Compaction, clearing the force flag has no effect.
[
https://issues.apache.org/jira/browse/HBASE-28272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
zhuyaogai updated HBASE-28272:
--
Description:
In the HStore.java class, in the requestCompaction method, after manually
triggering Major Compaction, this.forceMajor is set to true.
When clearing the force flag, execute the following code:
{code:java}
this.forceMajor = this.forceMajor && !request.isMajor(); {code}
However, when the table is applied to a Stripe Compaction strategy (other
compaction policy may have similar problems), request.isMajor() is always
false, because in CompactionRequestImpl the setIsMajor method is not always
called. We need to check the calling status of the setIsMajor method.
Otherwise, after a major is manually triggered, forceMajor will always be true,
and subsequent periodic compactions will also be forced to a major compaction.
was:
In the HStore.java class, in the requestCompaction method, after manually
triggering Major Compaction, this.forceMajor is set to true.
When clearing the force flag, execute the following code:
{code:java}
this.forceMajor = this.forceMajor && !request.isMajor(); {code}
However, when the table is a Stripe Compaction strategy (other compaction
policy may have similar problems), request.isMajor() is always false because,
in CompactionRequestImpl
The setIsMajor method is not always called. We need to check the calling status
of the setIsMajor method. Otherwise, after a major is manually triggered,
forceMajor will always be true, and subsequent periodic compactions will also
be forced to a major compaction.
> After triggering a Major Compaction, clearing the force flag has no effect.
> ---
>
> Key: HBASE-28272
> URL: https://issues.apache.org/jira/browse/HBASE-28272
> Project: HBase
> Issue Type: Bug
> Components: Compaction
>Affects Versions: 2.2.6
>Reporter: Longping Jie
>Priority: Major
>
> In the HStore.java class, in the requestCompaction method, after manually
> triggering Major Compaction, this.forceMajor is set to true.
> When clearing the force flag, execute the following code:
> {code:java}
> this.forceMajor = this.forceMajor && !request.isMajor(); {code}
> However, when the table is applied to a Stripe Compaction strategy (other
> compaction policy may have similar problems), request.isMajor() is always
> false, because in CompactionRequestImpl the setIsMajor method is not always
> called. We need to check the calling status of the setIsMajor method.
> Otherwise, after a major is manually triggered, forceMajor will always be
> true, and subsequent periodic compactions will also be forced to a major
> compaction.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (HBASE-28272) After triggering a Major Compaction, clearing the force flag has no effect.
[
https://issues.apache.org/jira/browse/HBASE-28272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
zhuyaogai updated HBASE-28272:
--
Description:
In the HStore.java class, in the requestCompaction method, after manually
triggering Major Compaction, this.forceMajor is set to true.
When clearing the force flag, execute the following code:
{code:java}
this.forceMajor = this.forceMajor && !request.isMajor(); {code}
However, when the table is a Stripe Compaction strategy (other compaction
policy may have similar problems), request.isMajor() is always false because,
in CompactionRequestImpl
The setIsMajor method is not always called. We need to check the calling status
of the setIsMajor method. Otherwise, after a major is manually triggered,
forceMajor will always be true, and subsequent periodic compactions will also
be forced to a major compaction.
was:
In the HStore.java class, in the requestCompaction method, after manually
triggering Major Compaction, this.forceMajor is set to true.
When clearing the force flag, execute the following code:
{code:java}
this.forceMajor = this.forceMajor && !request.isMajor(); {code}
However, when the table is a Stripe Compaction strategy (other compaction
policy may have similar problems), request.isMajor() is always false because,
in CompactionRequestImpl
The setIsMajor method is not always called. We need to check the calling status
of the setIsMajor method. Otherwise, after a major is manually triggered,
forceMajor will always be true, and subsequent periodic major compactions will
also be forced to compaction.
> After triggering a Major Compaction, clearing the force flag has no effect.
> ---
>
> Key: HBASE-28272
> URL: https://issues.apache.org/jira/browse/HBASE-28272
> Project: HBase
> Issue Type: Bug
> Components: Compaction
>Affects Versions: 2.2.6
>Reporter: Longping Jie
>Priority: Major
>
> In the HStore.java class, in the requestCompaction method, after manually
> triggering Major Compaction, this.forceMajor is set to true.
> When clearing the force flag, execute the following code:
> {code:java}
> this.forceMajor = this.forceMajor && !request.isMajor(); {code}
> However, when the table is a Stripe Compaction strategy (other compaction
> policy may have similar problems), request.isMajor() is always false because,
> in CompactionRequestImpl
> The setIsMajor method is not always called. We need to check the calling
> status of the setIsMajor method. Otherwise, after a major is manually
> triggered, forceMajor will always be true, and subsequent periodic
> compactions will also be forced to a major compaction.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (HBASE-28190) Add slow sync log rolling test in TestAsyncLogRolling
[ https://issues.apache.org/jira/browse/HBASE-28190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795568#comment-17795568 ] zhuyaogai commented on HBASE-28190: --- [~zhangduo] Okay, I will finish it as soon as possible. > Add slow sync log rolling test in TestAsyncLogRolling > - > > Key: HBASE-28190 > URL: https://issues.apache.org/jira/browse/HBASE-28190 > Project: HBase > Issue Type: Improvement > Components: test >Reporter: zhuyaogai >Assignee: zhuyaogai >Priority: Minor > > There is a test for slow sync log rolling in `TestLogRolling`, but not in > `TestAsyncLogRolling`, so add it in `TestAsyncLogRolling`. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HBASE-28190) Add slow sync log rolling test in TestAsyncLogRolling
zhuyaogai created HBASE-28190: - Summary: Add slow sync log rolling test in TestAsyncLogRolling Key: HBASE-28190 URL: https://issues.apache.org/jira/browse/HBASE-28190 Project: HBase Issue Type: Improvement Reporter: zhuyaogai Assignee: zhuyaogai There is a test for slow sync log rolling in `TestLogRolling`, but not in `TestAsyncLogRolling`, so add it in `TestAsyncLogRolling`. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HBASE-28107) Limit max count of rows filtered per scan request.
[ https://issues.apache.org/jira/browse/HBASE-28107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhuyaogai updated HBASE-28107: -- Component/s: regionserver > Limit max count of rows filtered per scan request. > -- > > Key: HBASE-28107 > URL: https://issues.apache.org/jira/browse/HBASE-28107 > Project: HBase > Issue Type: Improvement > Components: regionserver >Affects Versions: 3.0.0 >Reporter: zhuyaogai >Assignee: zhuyaogai >Priority: Major > > In some scenarios, when users do not understand the impact of the filters > they set, it may lead to a large number of rows being filtered, causing very > high CPU usage and system load, which may affect the requests of others. > Therefore, we need to have the defensive capability to detect and kill such > abnormal requests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (HBASE-28107) Limit max count of rows filtered per scan request.
[ https://issues.apache.org/jira/browse/HBASE-28107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhuyaogai reassigned HBASE-28107: - Assignee: zhuyaogai > Limit max count of rows filtered per scan request. > -- > > Key: HBASE-28107 > URL: https://issues.apache.org/jira/browse/HBASE-28107 > Project: HBase > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: zhuyaogai >Assignee: zhuyaogai >Priority: Major > > In some scenarios, when users do not understand the impact of the filters > they set, it may lead to a large number of rows being filtered, causing very > high CPU usage and system load, which may affect the requests of others. > Therefore, we need to have the defensive capability to detect and kill such > abnormal requests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HBASE-28107) Limit max count of rows filtered per scan request.
zhuyaogai created HBASE-28107: - Summary: Limit max count of rows filtered per scan request. Key: HBASE-28107 URL: https://issues.apache.org/jira/browse/HBASE-28107 Project: HBase Issue Type: Improvement Affects Versions: 3.0.0 Reporter: zhuyaogai In some scenarios, when users do not understand the impact of the filters they set, it may lead to a large number of rows being filtered, causing very high CPU usage and system load, which may affect the requests of others. Therefore, we need to have the defensive capability to detect and kill such abnormal requests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (HBASE-27853) Add client side table metrics for rpc calls and request latency.
[ https://issues.apache.org/jira/browse/HBASE-27853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhuyaogai reassigned HBASE-27853: - Assignee: zhuyaogai > Add client side table metrics for rpc calls and request latency. > > > Key: HBASE-27853 > URL: https://issues.apache.org/jira/browse/HBASE-27853 > Project: HBase > Issue Type: Improvement > Components: Client, metrics >Affects Versions: 3.0.0-alpha-3 >Reporter: zhuyaogai >Assignee: zhuyaogai >Priority: Major > > Now we can get client metrics to see number of calls or latency of related > RPC calls like get, mutate, scan etc... > But more often, we are more concerned about table level metrics, so we need > to subdivide them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HBASE-27853) Add client side table metrics for rpc calls and request latency.
zhuyaogai created HBASE-27853: - Summary: Add client side table metrics for rpc calls and request latency. Key: HBASE-27853 URL: https://issues.apache.org/jira/browse/HBASE-27853 Project: HBase Issue Type: Improvement Components: Client, metrics Affects Versions: 3.0.0-alpha-3 Reporter: zhuyaogai Now we can get client metrics to see number of calls or latency of related RPC calls like get, mutate, scan etc... But more often, we are more concerned about table level metrics, so we need to subdivide them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HBASE-27854) Add client side table metrics for rpc calls and request latency.
zhuyaogai created HBASE-27854: - Summary: Add client side table metrics for rpc calls and request latency. Key: HBASE-27854 URL: https://issues.apache.org/jira/browse/HBASE-27854 Project: HBase Issue Type: Improvement Components: Client, metrics Affects Versions: 3.0.0-alpha-3 Reporter: zhuyaogai Now we can get client metrics to see number of calls or latency of related RPC calls like get, mutate, scan etc... But more often, we are more concerned about table level metrics, so we need to subdivide them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HBASE-27845) Distinguish the mutate types of rpc error in MetricsConnection
[
https://issues.apache.org/jira/browse/HBASE-27845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
zhuyaogai updated HBASE-27845:
--
Summary: Distinguish the mutate types of rpc error in MetricsConnection
(was: Distinguish the mutate type of rpc error in MetricsConnection)
> Distinguish the mutate types of rpc error in MetricsConnection
> --
>
> Key: HBASE-27845
> URL: https://issues.apache.org/jira/browse/HBASE-27845
> Project: HBase
> Issue Type: Improvement
>Reporter: zhuyaogai
>Assignee: zhuyaogai
>Priority: Minor
>
> There are four mutate types in HBase, including {_}Append{_}, {_}Delete{_},
> {_}Increment{_}, and _Put._ However, when rpc error occurs on the client,
> mutate types are not distinguished in MetricsConnection.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (HBASE-27845) Distinguish the mutate type of rpc error in MetricsConnection
zhuyaogai created HBASE-27845:
-
Summary: Distinguish the mutate type of rpc error in
MetricsConnection
Key: HBASE-27845
URL: https://issues.apache.org/jira/browse/HBASE-27845
Project: HBase
Issue Type: Improvement
Reporter: zhuyaogai
There are four mutate types in HBase, including {_}Append{_}, {_}Delete{_},
{_}Increment{_}, and _Put._ However, when rpc error occurs on the client,
mutate types are not distinguished in MetricsConnection.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (HBASE-27845) Distinguish the mutate type of rpc error in MetricsConnection
[
https://issues.apache.org/jira/browse/HBASE-27845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
zhuyaogai reassigned HBASE-27845:
-
Assignee: zhuyaogai
> Distinguish the mutate type of rpc error in MetricsConnection
> -
>
> Key: HBASE-27845
> URL: https://issues.apache.org/jira/browse/HBASE-27845
> Project: HBase
> Issue Type: Improvement
>Reporter: zhuyaogai
>Assignee: zhuyaogai
>Priority: Minor
>
> There are four mutate types in HBase, including {_}Append{_}, {_}Delete{_},
> {_}Increment{_}, and _Put._ However, when rpc error occurs on the client,
> mutate types are not distinguished in MetricsConnection.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (HBASE-27268) In trace log mode, the client does not print callId/startTime and the server does not print receiveTime
[ https://issues.apache.org/jira/browse/HBASE-27268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhuyaogai updated HBASE-27268: -- Description: *Question:* In some scenarios in the production environment, users find that the request latancy is high on the client side, but it is not high on the server side (all through the internal monitor system). In this inconsistent scenario, we want to know if there is a problem with the client or the current network. Therefore, we want to know the time when the server receives the request. However, in Trace mode, no relevant information is printed. A possible solution is that the client prints callId (so we can associate the corresponding request on the server) and startTime about the request，and the server prints receiveTime about the request. In this way, we can find out at what stage the problem occurs. The client can even wrap the startTime in the request, and the server can directly collect the time at the network level (netty framework process time and network transmission time and so on) which make it easy to monitor some network level metrics about the client requests. was: Question: In some scenarios in the production environment, users find that the request latancy is high on the client side, but it is not high on the server side (all through the internal monitor system). In this inconsistent scenario, we want to know if there is a problem with the client or the current network. Therefore, we want to know the time when the server receives the request. However, in Trace mode, no relevant information is printed. A possible solution is that the client prints callId (so we can associate the corresponding request on the server) and startTime about the request，and the server prints receiveTime about the request. In this way, we can find out at what stage the problem occurs. The client can even wrap the startTime in the request, and the server can directly collect the time at the network level (netty framework process time and network transmission time and so on) for some network level trace monitoring purposes. > In trace log mode, the client does not print callId/startTime and the server > does not print receiveTime > --- > > Key: HBASE-27268 > URL: https://issues.apache.org/jira/browse/HBASE-27268 > Project: HBase > Issue Type: Improvement > Components: tracing >Affects Versions: 2.5.0, 3.0.0-alpha-3 >Reporter: zhuyaogai >Assignee: zhuyaogai >Priority: Minor > > *Question:* > In some scenarios in the production environment, users find that the request > latancy is high on the client side, but it is not high on the server side > (all through the internal monitor system). In this inconsistent scenario, we > want to know if there is a problem with the client or the current network. > Therefore, we want to know the time when the server receives the request. > However, in Trace mode, no relevant information is printed. > > A possible solution is that the client prints callId (so we can associate the > corresponding request on the server) and startTime about the request，and the > server prints receiveTime about the request. In this way, we can find out at > what stage the problem occurs. > > The client can even wrap the startTime in the request, and the server can > directly collect the time at the network level (netty framework process time > and network transmission time and so on) which make it easy to monitor some > network level metrics about the client requests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HBASE-27268) In trace log mode, the client does not print callId/startTime and the server does not print receiveTime
[ https://issues.apache.org/jira/browse/HBASE-27268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhuyaogai updated HBASE-27268: -- Description: Question: In some scenarios in the production environment, users find that the request latancy is high on the client side, but it is not high on the server side (all through the internal monitor system). In this inconsistent scenario, we want to know if there is a problem with the client or the current network. Therefore, we want to know the time when the server receives the request. However, in Trace mode, no relevant information is printed. A possible solution is that the client prints callId (so we can associate the corresponding request on the server) and startTime about the request，and the server prints receiveTime about the request. In this way, we can find out at what stage the problem occurs. The client can even wrap the startTime in the request, and the server can directly collect the time at the network level (netty framework process time and network transmission time and so on) for some network level trace monitoring purposes. was: Question: In some scenarios in the production environment, users find that the request latancy is high on the client side, but it is not high on the server side (all through the internal monitor system). In this inconsistent scenario, we want to know if there is a problem with the client or the current network. Therefore, we want to know the time when the server receives the request. However, in Trace mode, no relevant information is printed. A possible solution is that the client prints callId (so we can associate the corresponding request on the server) and startTime about the request，and the server prints receiveTime about the request. In this way, we can find out at what stage the problem occurs > In trace log mode, the client does not print callId/startTime and the server > does not print receiveTime > --- > > Key: HBASE-27268 > URL: https://issues.apache.org/jira/browse/HBASE-27268 > Project: HBase > Issue Type: Improvement > Components: tracing >Affects Versions: 2.5.0, 3.0.0-alpha-3 >Reporter: zhuyaogai >Assignee: zhuyaogai >Priority: Minor > > Question: > In some scenarios in the production environment, users find that the request > latancy is high on the client side, but it is not high on the server side > (all through the internal monitor system). In this inconsistent scenario, we > want to know if there is a problem with the client or the current network. > Therefore, we want to know the time when the server receives the request. > However, in Trace mode, no relevant information is printed. > > A possible solution is that the client prints callId (so we can associate the > corresponding request on the server) and startTime about the request，and the > server prints receiveTime about the request. In this way, we can find out at > what stage the problem occurs. > > The client can even wrap the startTime in the request, and the server can > directly collect the time at the network level (netty framework process time > and network transmission time and so on) for some network level trace > monitoring purposes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HBASE-27268) In trace log mode, the client does not print callId/startTime and the server does not print receiveTime
[ https://issues.apache.org/jira/browse/HBASE-27268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhuyaogai updated HBASE-27268: -- Description: Question: In some scenarios in the production environment, users find that the request latancy is high on the client side, but it is not high on the server side (all through the internal monitor system). In this inconsistent scenario, we want to know if there is a problem with the client or the current network. Therefore, we want to know the time when the server receives the request. However, in Trace mode, no relevant information is printed. A possible solution is that the client prints callId (so we can associate the corresponding request on the server) and startTime about the request，and the server prints receiveTime about the request. In this way, we can find out at what stage the problem occurs was: Question: In some scenarios in the production environment, users find that the request latancy is high on the client side, but it is not high on the server side (all through the internal monitor system). In this inconsistent scenario, we want to know if there is a problem with the client or the current network. Therefore, we want to know the time when the server receives the request. However, in Trace mode, no relevant information is printed. A possible solution is that the client prints > In trace log mode, the client does not print callId/startTime and the server > does not print receiveTime > --- > > Key: HBASE-27268 > URL: https://issues.apache.org/jira/browse/HBASE-27268 > Project: HBase > Issue Type: Improvement > Components: tracing >Affects Versions: 2.5.0, 3.0.0-alpha-3 >Reporter: zhuyaogai >Assignee: zhuyaogai >Priority: Minor > > Question: > In some scenarios in the production environment, users find that the request > latancy is high on the client side, but it is not high on the server side > (all through the internal monitor system). In this inconsistent scenario, we > want to know if there is a problem with the client or the current network. > Therefore, we want to know the time when the server receives the request. > However, in Trace mode, no relevant information is printed. > > A possible solution is that the client prints callId (so we can associate the > corresponding request on the server) and startTime about the request，and the > server prints receiveTime about the request. In this way, we can find out at > what stage the problem occurs -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HBASE-27268) In trace log mode, the client does not print callId/startTime and the server does not print receiveTime
[ https://issues.apache.org/jira/browse/HBASE-27268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhuyaogai updated HBASE-27268: -- Description: Question: In some scenarios in the production environment, users find that the request latancy is high on the client side, but it is not high on the server side (all through the internal monitor system). In this inconsistent scenario, we want to know if there is a problem with the client or the current network. Therefore, we want to know the time when the server receives the request. However, in Trace mode, no relevant information is printed. A possible solution is that the client prints was: Question: In some scenarios in the production environment, users find that the request latancy is high on the client side, but it is not high on the server side (all through the internal monitor system). In this inconsistent scenario, we want to know if there is a problem with the client or the current network. Therefore, we want to know the time when the server receives the request. However, in Trace mode, no relevant information is printed. A possible solution is that the > In trace log mode, the client does not print callId/startTime and the server > does not print receiveTime > --- > > Key: HBASE-27268 > URL: https://issues.apache.org/jira/browse/HBASE-27268 > Project: HBase > Issue Type: Improvement > Components: tracing >Affects Versions: 2.5.0, 3.0.0-alpha-3 >Reporter: zhuyaogai >Assignee: zhuyaogai >Priority: Minor > > Question: > In some scenarios in the production environment, users find that the request > latancy is high on the client side, but it is not high on the server side > (all through the internal monitor system). In this inconsistent scenario, we > want to know if there is a problem with the client or the current network. > Therefore, we want to know the time when the server receives the request. > However, in Trace mode, no relevant information is printed. > > A possible solution is that the client prints -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HBASE-27268) In trace log mode, the client does not print callId/startTime and the server does not print receiveTime
[ https://issues.apache.org/jira/browse/HBASE-27268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhuyaogai updated HBASE-27268: -- Summary: In trace log mode, the client does not print callId/startTime and the server does not print receiveTime (was: In trace log mode, the client does not print callId and the server does not print receiveTime) > In trace log mode, the client does not print callId/startTime and the server > does not print receiveTime > --- > > Key: HBASE-27268 > URL: https://issues.apache.org/jira/browse/HBASE-27268 > Project: HBase > Issue Type: Improvement > Components: tracing >Affects Versions: 2.5.0, 3.0.0-alpha-3 >Reporter: zhuyaogai >Assignee: zhuyaogai >Priority: Minor > > Question: > In some scenarios in the production environment, users find that the request > latancy is high on the client side, but it is not high on the server side > (all through the internal monitor system). In this inconsistent scenario, we > want to know if there is a problem with the client or the current network. > Therefore, we want to know the time when the server receives the request. > However, in Trace mode, no relevant information is printed. > > A possible solution is that the -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HBASE-27268) In trace log mode, the client does not print callId and the server does not print receiveTime
[ https://issues.apache.org/jira/browse/HBASE-27268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhuyaogai updated HBASE-27268: -- Description: Question: In some scenarios in the production environment, users find that the request latancy is high on the client side, but it is not high on the server side (all through the internal monitor system). In this inconsistent scenario, we want to know if there is a problem with the client or the current network. Therefore, we want to know the time when the server receives the request. However, in Trace mode, no relevant information is printed. A possible solution is that the was:In some scenarios in the production environment, users find that the request latancy is high on the client side, but it is not high on the server side (all through the internal monitor system). In this inconsistent scenario, we want to know if there is a problem with the client or the current network. Therefore, we want to know the time when the server receives the request. However, in Trace mode, no relevant information is printed. > In trace log mode, the client does not print callId and the server does not > print receiveTime > - > > Key: HBASE-27268 > URL: https://issues.apache.org/jira/browse/HBASE-27268 > Project: HBase > Issue Type: Improvement > Components: tracing >Affects Versions: 2.5.0, 3.0.0-alpha-3 >Reporter: zhuyaogai >Assignee: zhuyaogai >Priority: Minor > > Question: > In some scenarios in the production environment, users find that the request > latancy is high on the client side, but it is not high on the server side > (all through the internal monitor system). In this inconsistent scenario, we > want to know if there is a problem with the client or the current network. > Therefore, we want to know the time when the server receives the request. > However, in Trace mode, no relevant information is printed. > > A possible solution is that the -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HBASE-27268) In trace log mode, the client does not print callId and the server does not print receiveTime
[ https://issues.apache.org/jira/browse/HBASE-27268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhuyaogai updated HBASE-27268: -- Description: In some scenarios in the production environment, users find that the request latancy is high on the client side, but it is not high on the server side (all through the internal monitor system). In this inconsistent scenario, we want to know if there is a problem with the client or the current network. Therefore, we want to know the time when the server receives the request. However, in Trace mode, no relevant information is printed. > In trace log mode, the client does not print callId and the server does not > print receiveTime > - > > Key: HBASE-27268 > URL: https://issues.apache.org/jira/browse/HBASE-27268 > Project: HBase > Issue Type: Improvement > Components: tracing >Affects Versions: 2.5.0, 3.0.0-alpha-3 >Reporter: zhuyaogai >Assignee: zhuyaogai >Priority: Minor > > In some scenarios in the production environment, users find that the request > latancy is high on the client side, but it is not high on the server side > (all through the internal monitor system). In this inconsistent scenario, we > want to know if there is a problem with the client or the current network. > Therefore, we want to know the time when the server receives the request. > However, in Trace mode, no relevant information is printed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HBASE-27268) In Trace log mode, the client does not print callId and the server does not print receiveTime
[ https://issues.apache.org/jira/browse/HBASE-27268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhuyaogai updated HBASE-27268: -- Summary: In Trace log mode, the client does not print callId and the server does not print receiveTime (was: In Trace log mode, the client does not print CallId and the server does not print receiveTime) > In Trace log mode, the client does not print callId and the server does not > print receiveTime > - > > Key: HBASE-27268 > URL: https://issues.apache.org/jira/browse/HBASE-27268 > Project: HBase > Issue Type: Improvement > Components: tracing >Affects Versions: 2.5.0, 3.0.0-alpha-3 >Reporter: zhuyaogai >Assignee: zhuyaogai >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HBASE-27268) In trace log mode, the client does not print callId and the server does not print receiveTime
[ https://issues.apache.org/jira/browse/HBASE-27268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhuyaogai updated HBASE-27268: -- Summary: In trace log mode, the client does not print callId and the server does not print receiveTime (was: In Trace log mode, the client does not print callId and the server does not print receiveTime) > In trace log mode, the client does not print callId and the server does not > print receiveTime > - > > Key: HBASE-27268 > URL: https://issues.apache.org/jira/browse/HBASE-27268 > Project: HBase > Issue Type: Improvement > Components: tracing >Affects Versions: 2.5.0, 3.0.0-alpha-3 >Reporter: zhuyaogai >Assignee: zhuyaogai >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HBASE-27268) In Trace log mode, the client does not print CallId and the server does not print receiveTime
zhuyaogai created HBASE-27268: - Summary: In Trace log mode, the client does not print CallId and the server does not print receiveTime Key: HBASE-27268 URL: https://issues.apache.org/jira/browse/HBASE-27268 Project: HBase Issue Type: Improvement Components: tracing Affects Versions: 3.0.0-alpha-3, 2.5.0 Reporter: zhuyaogai Assignee: zhuyaogai -- This message was sent by Atlassian Jira (v8.20.10#820010)
