标签：tomcat

实现优先使用运行线程及调整线程数大小的线程池

当前在JDK中默认使用的线程池 ThreadPoolExecutor，在具体使用场景中，有以下几个缺点

  1. core线程一般不会timeOut
  2. 新任务提交时，如果工作线程数小于 coreSize，会自动先创建线程，即使当前工作线程已经空闲，这样会造成空闲线程浪费
  3. 设置的maxSize参数只有在队列满之后，才会生效，而默认情况下容器队列会很大(比如1000)

如一个coreSize为10，maxSize为100,队列长度为1000的线程池，在运行一段时间之后的效果会是以下2个效果:

  1. 系统空闲时，线程池中始终保持10个线程不变，有一部分线程在执行任务，另一部分线程一直wait中(即使设置allowCoreThreadTimeOut)
  2. 系统繁忙时，线程池中线程仍然为10个，但队列中有还没有执行的任务(不超过1000),存在任务堆积现象

本文将描述一下简单版本的线程池，参考于 Tomcat ThreadPoolExecutor, 实现以下3个目标

  1. 新任务提交时，如果有空闲线程，直接让空闲线程执行任务，而非创建新线程
  2. 如果coreSize满了，并且线程数没有超过maxSize，则优先创建线程，而不是放入队列
  3. 其它规则与ThreadPoolExecutor一致，如 timeOut机制
继续阅读“实现优先使用运行线程及调整线程数大小的线程池”

使用spring boot和embedded tomcat开发时出现404找不到jsp问题的处理

初使用spring boot时,出现程序中配置了相应的指向地址,但前端界面始终报找不到jsp界面的404错误.但相同的程序在另一位同事时却正常工作.因此,有必要从源码角度分析一下,spring boot如何和embedded tomcat进行相应的整合.

本文开发时使用的为idea,相应的jsp放置在标准的src/main/webapp目录下,并且spring mvc也配置了 spring.mvc.view.prefix各项网上都能找到的配置信息.

首先是先将一个最简单的jsp文件放置在src/main/webapp,然后启动程序,直接访问此jsp(不通过mvc跳转), 仍然返回404.这就表示实际上这个src/main/webapp并没有被spring boot中tomcat所识别. 一般认为这个目录就是一个放置资源信息的地址目录,那么这里404表示在启动过程中,这个目录并没有被正常找到.

因为spring boot并没有一个显示配置项来配置此位置(从hello的demo来看),因此此地址的查找为一个简单的逻辑过程.从tomcat的角度来看,这属于一个documentRoot,即项目文件根目录,从尝试从整个源码中搜索有关于documentRoot,或者说对于tomcat一个上下文来讲为docBase的概念.最终找到的位置为 TomcatEmbeddedServletContainerFactory#prepareContext 方法.

简单的代码来看,主要的代码如下所示:

		File docBase = getValidDocumentRoot();
		docBase = (docBase != null ? docBase : createTempDir("tomcat-docbase"));
		context.setDocBase(docBase.getAbsolutePath());

继续阅读“使用spring boot和embedded tomcat开发时出现404找不到jsp问题的处理”

spring LTW agent方式在tomcat 8下无效

在常规的spring ltw中，我们对tomcat使用ltw，一般是以下两种方式。

//1 在启动项中添加javaagent选项
-javaagent:e:/spring-instrument-4.1.1.RELEASE.jar

//2 使用自定义的启动器，在META-INF/context.xml中增加以下内容
<?xml version="1.0" encoding="UTF-8" ?>
<Context>
 <Loader loaderClass="org.springframework.instrument.classloading.tomcat.TomcatInstrumentableClassLoader" /> 
</Context>

这两种方式在tomcat6以及tomcat7均可以正常工作。但对于tomcat8，第1种方式已经不能再工作，仅能使用第二种方式。原因就在于tomcat8的webClassLoader已经提供了InstrumentableClassLoader接口。此接口将导致spring直接将aspectj的AspectJClassBypassingClassFileTransformer 直接添加到tomcat的classLoader中。但由于不是很正确的实现方式，导致aspect在使用tomcat8提供的classLoader时，并不能有效地对自己的advice进行weaver，导致报以下的错误信息： 

java.lang.NoSuchMethodError: XXXAdvice.aspectOf()LXXXAdvice;
 atXXX.index(AbcController.java:30)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at org.springframework.web.method.support.InvocableHandlerMethod.invoke(InvocableHandlerMethod.java:215)
 at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:132)
 at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:104)

这个错误的产生在于aspectJ的初始化过程和classLoader之间的交互行为，以及tomcat8中不准确的缓存行为。

继续阅读“spring LTW agent方式在tomcat 8下无效”

transfer-encoding和content-length的不同实现

前段时间在项目中看到如下的代码：

		HttpServletResponse response = (HttpServletResponse)servletResponse;
		response.setHeader("Transfer-Encoding", "utf8");
		filterChain.doFilter(servletRequest, servletResponse);

原意是想对输出的内容进行编码，却用错了响应头，结果这个错误的响应头对后面的客户端程序带来了许多麻烦。这里有必要对这个这块的内容进行详细地了解。

传输数据编码：Transfer-Encoding
数据编码，即表示数据在网络传输当中，使用怎么样的保证方式来保证数据是安全成功地传输处理。可以是分段传输，也可以是不分段，直接使用原数据进行传输。
有效的值为：Trunked和Identity.
传输内容编码：Content-Encoding
内容编码，即整个数据信息是在数据器端经过怎样的编码处理，然后客户端会以怎么的编码来反向处理，以得到原始的内容。这里的内容编码主要是指压缩编码，即服务器端压缩，客户端解压缩。
可以参考的值为：gzip,compress,deflate和identity。
传输内容格式：Content-Type
内容格式，即接收的数据最终是以何种的形式显示在浏览器中。可以是一个图片，还是一段文本，或者是一段html。内容格式额外支持可选参数,charset，即实际内容的字符集。通过字符集，客户端可以对数据进行解编码，以最终显示可以看得懂的文字（而不是一段byte[]或者是乱码)。

3种描述信息，可以由下图来表示(来源于《Http权威指南》)：

从上文中，可以看出，实际上原filter中的内容可能是想表达以下的意思:

response.setContentType("text/html;charset=UTF8");
//或者
response.setContentType("application/json;charset=UTF8");

继续阅读“transfer-encoding和content-length的不同实现”

tomcat如何访问jndi信息

在上一篇我们知道tomcat在启动时会解析context.xml并将相应的数据源信息解析到上下文中。那么接下来的工作就是如何去访问这个数据源信息了。我们访问数据源信息是通过以下代码进行访问的 

InitialContext initialContext = new InitialContext();
	DataSource dataSource = (DataSource) initialContext.lookup("java:comp/env/jdbc/xx");

那么我们就按照这个访问思路跟踪一下代码。我们看一下InitialContext的lookup实现，如下所示：

public Object lookup(String name) throws NamingException {
	return getURLOrDefaultInitCtx(name).lookup(name);
    }

这里会取得一个UrlContext或InitContext，究竟取得哪个取决于传递的参数信息，这里我们的方法是以java:开头，即它有一个scheme_id信息，按照官方对于传递的URL字符串规则，显示如下所示（该描述在javadoc中的InitialContext中）：

解析 URL 字符串时生成此策略的一个异常，如下所述。
 在将 URL 字符串（一个 scheme_id:rest_of_name 形式的 String）作为名称参数传递给任一方法时，将定位处理该方案的一个 URL 上下文工厂，并
将它用于解析该 URL。如果没有找到这样的工厂，则使用由 "java.naming.factory.initial" 指定的初始上下文。类似地，当将第一个组件是 URL 字
符串的 CompositeName 对象作为名称参数传递给任一方法时，将定位一个 URL 上下文工厂并将它用于解析第一个名称组件

因此，它将尝试找一个URLContext，而在前文中我们提到在tomcat支持命名服务中，设置了一个Context.URL_PKG_PREFIXES参数为org.apache.naming，因此，会尝试寻找一个名叫
org.apache.naming.java.javaURLContextFactory的类，而恰好存在这个类。那么InitContext将转向这个类，再从这个类找回一个UrlContext实例，具体实现如下所示：

继续阅读“tomcat如何访问jndi信息”

tomcat如何解析resource数据源

我们都知道在tomcat中，可以通过在context.xml中配置resource中用于配置tomcat数据源，如下所示即是一个配置例子。

<Context>
	<Resource name="jdbc/xx" auth="Container" type="javax.sql.DataSource" password="mymysql"
			  driverClassName="com.mysql.jdbc.Driver"
			  username="root" url="jdbc:mysql://127.0.0.1/xx"
			  />
</Context>

配置了如上的数据源之后，在java代码中，就可以以如下代码进行访问：

         InitialContext initialContext = new InitialContext();
	DataSource dataSource = (DataSource) initialContext.lookup("java:comp/env/jdbc/xx");

那么,tomcat是如何将resource中的信息解析成上下文中，并可以通过jndi的方式进行访问呢。这就得从contextResource对象的创建说起。

在NamingContextListener中，namingContext被创建，同时相应的comp上下文和evn上下文被创建起来。然后通过解析context.xml，将最终的jdbc/xx节点绑定在相应的上下文中，并通过解析Resource节点，最终确定数据源对象的创建。

继续阅读“tomcat如何解析resource数据源”