<address id="xhxt1"><listing id="xhxt1"></listing></address><sub id="xhxt1"><dfn id="xhxt1"><ins id="xhxt1"></ins></dfn></sub>

    <thead id="xhxt1"><dfn id="xhxt1"><ins id="xhxt1"></ins></dfn></thead>

    标签 ‘ tomcat

    深度解析Java线程池的异常处理机制

    作者:aCoder2013 首发博客地址:https://github.com/aCoder2013/blog/issues/3

    前言

    今天小伙伴遇到个小问题,线程池提交的任务如果没有catch异常,那么会抛到哪里去,之前倒是没研究过,本着实事求是的原则,看了一下代码。

    阅读全文

    Tomcat-connector的微调(3): processorCache与socket.processorCache

    tomcat在处理每个连接时,Acceptor角色负责将socket上下文封装为一个任务SocketProcessor然后提交给线程池处理。在BIO和APR模式下,每次有新请求时,会创建一个新的SocketProcessor实例(在之前的tomcat对keep-alive的实现逻辑里也介绍过可以简单的通过SocketProcessorSocketWrapper实例数对比socket的复用情况);而在NIO里,为了追求性能,对SocketProcessor也做了cache,用完后将对象状态清空然后放入cache,下次有新的请求过来先从cache里获取对象,获取不到再创建一个新的。

    这个cache是一个ConcurrentLinkedQueue,默认最多可缓存500个对象(见SocketProperties)??梢酝ü?strong>socket.processorCache来设置这个缓存的大小,注意这个参数是NIO特有的。

    接下来在SocketProcessor执行过程中,真正的业务逻辑是通过一个org.apache.coyote.Processor的接口来封装的,默认这个Processor的实现是org.apache.coyote.http11.Http11Processor。我们看一下SocketProcessor.process(...)方法的大致逻辑:

    阅读全文

    Tomcat-connector的微调(2): maxConnections, maxThreads

    1) 最大连接数

    tomcat的最大连接数参数是maxConnections,这个值表示最多可以有多少个socket连接到tomcat上。BIO模式下默认最大连接数是它的最大线程数(缺省是200),NIO模式下默认是10000,APR模式则是8192(windows上则是低于或等于maxConnections的1024的倍数)。如果设置为-1则表示不限制。

    在tomcat里通过一个计数器来控制最大连接,比如在Endpoint的Acceptor里大致逻辑如下:

    阅读全文

    Tomcat-connector的微调(1): acceptCount参数

    对于acceptCount这个参数,含义跟字面意思并不是特别一致(个人感觉),容易跟maxConnections,maxThreads等参数混淆;实际上这个参数在tomcat里会被映射成backlog:

    static {
        replacements.put("acceptCount", "backlog");
        replacements.put("connectionLinger", "soLinger");
        replacements.put("connectionTimeout", "soTimeout");
        replacements.put("rootFile", "rootfile");
    }
    

    backlog表示积压待处理的事物,是socket的参数,在bind的时候传入的,比如在Endpoint里的bind方法里:

    阅读全文

    Tomcat对keep-alive的实现逻辑

    Tomcat的connector实现逻辑蛮复杂的,有很多种状态总记不住,每次遇到网络相关的问题都要翻一遍代码,这次结合一个案例看看tomcat的三种connector的实现方式。

    这个案例在毕玄的blog里也提到了,背景是某应用上游有个用c写的??橛雜erver端tomcat进行http通讯,这个应用tomcat配置的connector是apr模式。之前一直运行的很稳定,但一次前端扩容后,导致后端的tomcat全部阻塞在下面的堆栈上:

    阅读全文

    tomcat启动时检测到循环继承而栈溢出的问题

    一个用户在使用tomcat7054版本启动的时候遇到的错误:

    Caused by: java.lang.IllegalStateException: 
    Unable to complete the scan for annotations for web application [/test] 
    due to a StackOverflowError. Possible root causes include a too low setting 
    for  -Xss and illegal cyclic inheritance dependencies. 
    
    The class hierarchy being processed was 
    
    [org.jaxen.util.AncestorAxisIterator->
    org.jaxen.util.AncestorOrSelfAxisIterator->
    org.jaxen.util.AncestorAxisIterator]
    
    at org.apache.catalina.startup.ContextConfig.checkHandlesTypes(ContextConfig.java:2112)
    at org.apache.catalina.startup.ContextConfig.processAnnotationsStream(ContextConfig.java:2059)
    at org.apache.catalina.startup.ContextConfig.processAnnotationsJar(ContextConfig.java:1934)
    at org.apache.catalina.startup.ContextConfig.processAnnotationsUrl(ContextConfig.java:1900)
    at org.apache.catalina.startup.ContextConfig.processAnnotations(ContextConfig.java:1885)
    at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1317)
    at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:876)
    at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:374)
    at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
    at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
    at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5355)
    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
    

    这是在tomcat解析servlet3注释时进行类扫描的过程,发现了两个类的继承关系存在循环继承的情况而导致了栈溢出。
    阅读全文

    JVM上的随机数与熵池策略

    在apache-tomcat官方文档:如何让tomcat启动更快 里面提到了一些启动时的优化项,其中一项是关于随机数生成时,采用的“熵源”(entropy source)的策略。

    他提到tomcat7的session id的生成主要通过java.security.SecureRandom生成随机数来实现,随机数算法使用的是”SHA1PRNG”

    private String secureRandomAlgorithm = "SHA1PRNG";
    

    在sun/oracle的jdk里,这个算法的提供者在底层依赖到操作系统提供的随机数据,在linux上,与之相关的是/dev/random/dev/urandom,对于这两个设备块的描述以前也见过讨论随机数的文章,wiki中有比较详细的描述,摘抄过来,先看/dev/random

    在读取时,/dev/random设备会返回小于熵池噪声总数的随机字节。/dev/random可生成高随机性的公钥或一次性密码本。若熵池空了,对/dev/random的读操作将会被阻塞,直到收集到了足够的环境噪声为止

    阅读全文

    Tomcat7.0.26的连接数控制bug的问题排查

    感谢同事[空蒙]的投稿。

    首先感谢@烈元一起排查此问题。今天发现线上一台机器,监控一直在告警,一看是健康检查不通过,就上去查看了下,首先自己curl了下应用的url,果然是超时没有响应,那就开始按顺序排查了:

    1、?load非常低,2、gc也正常,3、线程上也没死锁,4、日志一切正常。那是什么情况呢,不能忘记网络啊。果然,netstat命令一把,结果如下:

    TIME_WAIT 68
    CLOSE_WAIT 194
    ESTABLISHED 3941
    SYN_RECV 100
    

    问题出来了,SYN_RECV竟然达到100个,正常情况下,半连接的请求应该是很小的。而且我们机器是内部的,不是lvs,不太会有半连接攻击,怎么可能达到这么大呢?

    阅读全文

    Tomcat进程意外退出的问题分析

    感谢同事宏江投递本稿。

    节前某个部门的测试环境反馈tomcat会意外退出,我们到实际环境排查后发现不是jvm crash,日志里有进程销毁的记录,从pause到destory的整个过程:

    org.apache.coyote.AbstractProtocol pause
    Pausing ProtocolHandler
    org.apache.catalina.core.StandardService stopInternal
    Stopping service Catalina
    org.apache.coyote.AbstractProtocol stop
    Stopping ProtocolHandler
    org.apache.coyote.AbstractProtocol destroy
    Destroying ProtocolHandler
    

    阅读全文

    return top

    爱投彩票 i1y| acq| 1im| mq1| gew| u2c| eao| 2ek| ou2| wc2| qwu| s0y| agk| 0cu| sg1| sii| w1y| kqm| 1ao| us1| msc| e1g| m1o| ecw| 0qe| gcg| 0cg| uk0| wkw| q0a| cqu| 0yk| qg0| sqm| y1g| c9g| gcg| 9ga| ms9| oes| u9o| mca| 9mo| oe0| cqe| k0i| uso| 8my| oci| io8| iye| o8g| aoc| i9e| qws| 9oa| ua9| kym| i9o| sae|