Poison


  • 首页

  • 归档

  • 标签

  • 搜索
close
Poison

Hessian Lite #63

发表于 2022-12-26
Reference

Support deserialization of nested generics (Byte/Short) by tianshuang · Pull Request #63 · apache/dubbo-hessian-lite · GitHub

Poison

GC Timestamp

发表于 2022-12-16

今天查了个 GC 相关的问题,问题并不复杂,只是在比对 GC 日志中的时间与业务超时调用的时间时发现有一点偏差,原来是因为 GC 日志中的时间戳是 GC 开始前的时间戳,而我之前一直以为是 GC 完成后的时间。比如如下 GC 日志:

1
2
2022-12-16T11:10:04.939+0800: 87938160.092: [GC (Allocation Failure) 2022-12-16T11:10:04.939+0800: 87938160.092: [ParNew (promotion failed): 1850515K->1850515K(1850624K), 0.6136336 secs]2022-12-16T11:10:05.552+0800: 87938160.706: [CMS2022-12-16T11:10:06.272+0800: 87938161.426: [CMS-concurrent-mark: 1.702/2.321 secs] [Times: user=0.00 sys=0.00, real=2.32 secs] 
(concurrent mode failure): 8844971K->9005083K(9697280K), 7.7882370 secs] 10643921K->9005083K(11547904K), [Metaspace: 99728K->99728K(1140736K)], 8.4022234 secs] [Times: user=0.00 sys=0.00, real=8.40 secs]
阅读全文 »
Poison

RST

发表于 2022-12-09

接收到 RST 包后的处理逻辑位于 tcp_input.c at v4.15:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
/* When we get a reset we do this. */
void tcp_reset(struct sock *sk)
{
trace_tcp_receive_reset(sk);

/* We want the right error as BSD sees it (and indeed as we do). */
switch (sk->sk_state) {
case TCP_SYN_SENT:
sk->sk_err = ECONNREFUSED;
break;
case TCP_CLOSE_WAIT:
sk->sk_err = EPIPE;
break;
case TCP_CLOSE:
return;
default:
sk->sk_err = ECONNRESET;
}
/* This barrier is coupled with smp_rmb() in tcp_poll() */
smp_wmb();

tcp_done(sk);

if (!sock_flag(sk, SOCK_DEAD))
sk->sk_error_report(sk);
}
阅读全文 »
Poison

SPR-11106

发表于 2022-12-05

今天看了个小问题,即日志中出现了 OOM,但是发现没有对应的堆转储生成,导致 Agent 未监控到 OOM,仔细查看相关日志,发现是 Spring 的请求处理逻辑中对 Throwable 进行了 catch 然后包装了相关异常,该组应用使用的 Spring 版本为 5.3.20,相关源码位于 DispatcherServlet.java at v5.3.20:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
/**
* Process the actual dispatching to the handler.
* <p>The handler will be obtained by applying the servlet's HandlerMappings in order.
* The HandlerAdapter will be obtained by querying the servlet's installed HandlerAdapters
* to find the first that supports the handler class.
* <p>All HTTP methods are handled by this method. It's up to HandlerAdapters or handlers
* themselves to decide which methods are acceptable.
* @param request current HTTP request
* @param response current HTTP response
* @throws Exception in case of any kind of processing failure
*/
@SuppressWarnings("deprecation")
protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception {
HttpServletRequest processedRequest = request;
HandlerExecutionChain mappedHandler = null;
boolean multipartRequestParsed = false;

WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager(request);

try {
ModelAndView mv = null;
Exception dispatchException = null;

try {
processedRequest = checkMultipart(request);
multipartRequestParsed = (processedRequest != request);

// Determine handler for the current request.
mappedHandler = getHandler(processedRequest);
if (mappedHandler == null) {
noHandlerFound(processedRequest, response);
return;
}

// Determine handler adapter for the current request.
HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());

// Process last-modified header, if supported by the handler.
String method = request.getMethod();
boolean isGet = HttpMethod.GET.matches(method);
if (isGet || HttpMethod.HEAD.matches(method)) {
long lastModified = ha.getLastModified(request, mappedHandler.getHandler());
if (new ServletWebRequest(request, response).checkNotModified(lastModified) && isGet) {
return;
}
}

if (!mappedHandler.applyPreHandle(processedRequest, response)) {
return;
}

// Actually invoke the handler.
mv = ha.handle(processedRequest, response, mappedHandler.getHandler());

if (asyncManager.isConcurrentHandlingStarted()) {
return;
}

applyDefaultViewName(processedRequest, mv);
mappedHandler.applyPostHandle(processedRequest, response, mv);
}
catch (Exception ex) {
dispatchException = ex;
}
catch (Throwable err) {
// As of 4.3, we're processing Errors thrown from handler methods as well,
// making them available for @ExceptionHandler methods and other scenarios.
dispatchException = new NestedServletException("Handler dispatch failed", err);
}
processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);
}
catch (Exception ex) {
triggerAfterCompletion(processedRequest, response, mappedHandler, ex);
}
catch (Throwable err) {
triggerAfterCompletion(processedRequest, response, mappedHandler,
new NestedServletException("Handler processing failed", err));
}
finally {
if (asyncManager.isConcurrentHandlingStarted()) {
// Instead of postHandle and afterCompletion
if (mappedHandler != null) {
mappedHandler.applyAfterConcurrentHandlingStarted(processedRequest, response);
}
}
else {
// Clean up any resources used by a multipart request.
if (multipartRequestParsed) {
cleanupMultipart(processedRequest);
}
}
}
}
阅读全文 »
Poison

JDK-8297173

发表于 2022-11-17

本来是排查 JDK-8265836 导致的 CPU 使用率不准确的问题,无意发现该修复方案存在一点小问题,顺手提交了个 PR 进行修复。

Reference

Java SE OperatingSystemMXBean.getSystemCpuLoad() Method Returns Incorrect Value in Containers
8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load inside a container by tanghaoth90 · Pull Request #3656 · openjdk/jdk · GitHub
8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load … · openjdk/jdk@ef368b3 · GitHub
JDK-8297173 usageTicks and totalTicks should be volatile to ensure that different threads get the latest ticks - Java Bug System

123…26

130 日志
119 标签
GitHub LeetCode
© 2025 Poison 蜀ICP备16000644号
由 Hexo 强力驱动
主题 - NexT.Mist