Tomcat

docker-compose简介 Compose是用于定义和运行多容器Docker应用程序的工具。通过Compose，您可以使用YAML文件来配置应用程序的服务。然后，使用一个命令，就可以从配置中创建并启动所有服务。 使用Compose基本上是一个三步过程： 1.使用定义您的应用环境，Dockerfile以便可以在任何地方复制。 2.定义组成应用程序的服务，docker-compose.yml 以便它们可以在隔离的环境中一起运行。 3. docker-compose up 启动并运行您的整个应用程序。 在linux下安装docker-compose 1.下载 #官方文档下载地址 有点慢 sudo curl -L "https://github.com/docker/compose/releases/download/1.26.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose #国内镜 像地址下载 curl -L "https://get.daocloud.io/docker/compose/releases/download/1.25.5/docker-compose-`uname -s`-`uname -m`" -o /usr/local/bin/docker-compose 2

一、前言 这两天看tomcat，查阅 tomcat 怎么承载高并发时，看到了backlog参数。我们知道，服务器端一般使用mq来减轻高并发下的洪峰冲击，将暂时不能处理的请求放入队列，后续再慢慢处理。其实操作系统已经帮我们做了一些类似的东西了，这个东西就是backlog。服务端一般通过 accept 调用，去获取socket。但是假设我们的程序处理不过来（比如因为程序bug，或者设计问题，没能及时地去调用 accept），那么此时的网络请求难道就直接丢掉吗？ 当然不会！这时候，操作系统会帮我们放入 accept 队列，先暂存起来。等我们的程序缓过来了，直接调用 accept 去 队列取就行了，这就达到了类似mq的效果。 而 backlog，和另一个参数 /proc/sys/net/core/somaxconn 一起，决定了队列的容量，算法为：min(/proc/sys/net/core/somaxconn, backlog) 。 文章比较长，如果只需要结论，看第三章的总结即可，有时间的话，可以仔细看看正文、第四章的验证部分。 如果只想知道怎么设置这个值，直接跳到最后即可。 下面这篇文章，基础原理讲得很不错。但是是外国人写的，我这里简（tong）单（ku）翻译一下，我也会结合自己的理解，做一些补充。原文链接： http://veithen.io/2014/01/01/how-tcp

解决413 Request Entity Too Large nginx/1.14.0 解决方法： nginx的error.log的错误日志： 2018/10/17 16:31:45 [error] 23693#0: *76448222 client intended to send too large body: 1329896 bytes, client: 192.168.1.101, server: , request: "POST /shortMessage HTTP/1.1", host: "192.168.1.113:8500" 其中1329896 bytes是1.2M，也就是说请求的数据达到了1.2M，超过了nginx的默认上传文件大小限制，默认1M. 修改配置如下： 1.在nginx.conf的http中添加以下配置： client_body_buffer_size 128k; client_max_body_size 16m; 2.在tomcat的Connector中添加以下属性： maxPostSize="-1" 本文链接： http://www.yayihouse.com/yayishuwu/chapter/1641 来源： oschina 链接： https://my.oschina.net/u/4291687/blog/4315263

目录 maven工程拆分与聚合的思想 maven普通项目和与拆分项目对比 maven解决代码可重用和便于维护的方案 工程和模块的区别 maven拆分与聚合的三种启动方式 （1）启动父工程:可以直接启动 （2）启动web工程 （3）配置本地tomcat maven工程拆分与聚合的思想 业务场景 看订单操作 买家：买家要看到订单，必须把数据库中订单数据查询出来。dao层的任务。 卖家：卖家要到订单，必须把数据库中订单数据查询出来。dao层的任务。 一份代码可重用：如果修改维护的话，只用修改一份。 一份代码复制粘贴到不同的地方：复制粘贴几个地方，就要维护及各个地方。 传统ssm框架整合的项目：我们要在每个项目中都防止一套ssm框架的jar包。 如果是maven的ssm工程，有十个项目，我们只需要一套jar包。真正项目中只用放置jar的坐标即可。 maven普通项目和与拆分项目对比 maven解决代码可重用和便于维护的方案 maven把一个完整的项目，分层不同的独立模块，这些模块都有各自独立的坐标。哪个地方需要其中某个模块，就直接引用该模块的坐标即可。 今后如果公司开发一个新项目，我们先考虑问题不是dao, service, utils, domain如何编写， 我们考虑的是，dao, service, utils, domain这些模块是否已经存在，如果存在直接引用。

Tomcat8之后，针对Http协议默认使用org.apache.coyote.http11.Http11NioProtocol，也就是NIO模式。通过之前的博客分析，我们知道Connector组件在初始化和start的时候会触发它子组件（Http11NioProtocol、NIOEndpoint的初始化和start）。 NIO模式工作时序图 还是像之前那样，我们先整理出NIO模式启动时的时序图。 从上面的时序图可以看出，整个流程的重点时在NioEndpoint这个类中。下面我们通过源代码看下这几个重点方法。 //NIO模式绑定端口 public void bind() throws Exception { //初始化套接字服务，需要注意的是在NIO模式下，这个ServerSocketChannel还是阻塞模式的 initServerSocket(); //设置默认的acceptor线程数，默认是1个，这个参数暂时好像没法修改（？？） //注意这个参数和acceptCount（接收请求连接的数量）之间的区别 if (acceptorThreadCount == 0) { acceptorThreadCount = 1; } //设置pollerThreadCount，根据CPU的核数来，CPU大于2个设置为2，否则为1 if (pollerThreadCount <= 0)

docker-compose部署配置jenkins 一、docker-compose文件 version: '3.1' services: jenkins: image: jenkins/jenkins:lts volumes: - /data/jenkins/:/var/jenkins_home - /var/run/docker.sock:/var/run/docker.sock - /usr/bin/docker:/usr/bin/docker - /usr/lib/x86_64-linux-gnu/libltdl.so.7:/usr/lib/x86_64-linux-gnu/libltdl.so.7 ports: - "8080:8080" expose: - "8080" - "50000" privileged: true user: root restart: always container_name: jenkins environment: JAVA_OPTS: '-Djava.util.logging.config.file=/var/jenkins_home/log.properties' root@zpl:/opt/jenkins# docker-compose up -d 然后ip+端口访问 二、解锁jenkins root@zpl:/opt

这周我们学习了在linux系统下安装jdk、tomcat以及mysql。下面我来简要概括一下安装jdk的过程以及需要进行的一些操作。 首先，我们在opt这个目录下创建两个文件夹install以及bigdata，在opt/install这个目录下安装源文件，在opt/bigdata这个目录下安装目录。 在x’ftp中opt/install这个目录下上传jdk的安装包，我们使用的版本如下图所示。 上传成功后，进入opt/install下使用ls命令看看安装包是上传成功。 下面开始进行安装包的解压操作。-C 后面跟着你的安装路径。 tar -zxvf jdk-8u111 -linux-x64.tar.gz -C /opt/bigdata/ 由于 jdk-8u111 -linux-x64的名字有些长，我们可以进行重命名操作，进入opt/bigdata这个目录 mv jdk-8u111 -linux-x64 jdk180 下面开始配置jdk的环境变量 vi etc/profile export JAVAHOME=/opt/bigdata/java/jdk180 export PATH=$JAVAHOME/bin:$PATH export CLASSPATH=.:$JAVAHOME/lib/dt.jar:$JAVAHOME/lib/tools.jar 随后激活环境变量 source /etc

告警 正在开会，突然钉钉告警声响个不停，同时市场人员反馈客户在投诉系统登不进了，报504错误。查看钉钉上的告警信息，几台业务服务器节点全部报CPU超过告警阈值，达100%。 赶紧从会上下来，SSH登录服务器，使用 top 命令查看，几个Java进程CPU占用达到180%，190%，这几个Java进程对应同一个业务服务的几个Pod（或容器）。 定位 使用 docker stats 命令查看本节点容器资源使用情况，对占用CPU很高的容器使用 docker exec -it <容器ID>bash 进入。 在容器内部执行 top 命令查看，定位到占用CPU高的进程ID，使用 top -Hp <进程ID> 定位到占用CPU高的线程ID。 使用 jstack <进程ID> > jstack.txt 将进程的线程栈打印输出。 退出容器， 使用 docker cp <容器ID>:/usr/local/tomcat/jstack.txt ./ 命令将jstack文件复制到宿主机，便于查看。获取到jstack信息后，赶紧重启服务让服务恢复可用。 5.将2中占用CPU高的线程ID使用 pringf '%x\n' <线程ID> 命令将线程ID转换为十六进制形式。假设线程ID为133，则得到十六进制85。在jstack.txt文件中定位到 nid=0x85的位置，该位置即为占用CPU高线程的执行栈信息

本文总结自实习中对项目的重构。原先项目采用Springboot+freemarker模版，开发过程中觉得前端逻辑写的实在恶心，后端Controller层还必须返回Freemarker模版的ModelAndView，逐渐有了前后端分离的想法，由于之前，没有接触过，主要参考的还是网上的一些博客教程等，初步完成了前后端分离，在此记录以备查阅。 一、前后端分离思想 前端从后端剥离，形成一个前端工程，前端只利用Json来和后端进行交互，后端不返回页面，只返回Json数据。前后端之间完全通过public API约定。 二、后端 Springboot Springboot就不再赘述了，Controller层返回Json数据。 @RequestMapping(value = "/add", method = RequestMethod.POST) @ResponseBody public JSONResult addClient(@RequestBody String param) { JSONObject jsonObject = JSON.parseObject(param); String task = jsonObject.getString("task"); List<Object> list = jsonObject.getJSONArray("attributes"); List

先感谢一下scz大佬给的博客推荐，受宠若惊+10086。 心血来潮有这么个想法，验证一下。 只讨论思路，工具木有~ 前言 看了很多师傅们在研究针对Java中间件+Java反序列化漏洞回显的研究： https://xz.aliyun.com/t/7740 https://xz.aliyun.com/t/7348 https://paper.seebug.org/1233/ （。。。应该还有挺多，就不翻了） 又看到了c0ny1师傅的作品： 《java内存对象搜索辅助工具》 配合IDEA在Java应用运行时，对内存中的对象进行搜索。比如可以可以用挖掘request对象用于回显等场景。 … 按照经验来讲Web中间件是多线程的应用，一般requst对象都会存储在线程对象中，可以通过 Thread.currentThread() 或 Thread.getThreads() 获取。 并且目前回显思路主要是基于加载类，执行static块或者构造方法（原生反序列化、FastJson、Jackson一类的都有）： TemplatesImpl类的反序列化链，内嵌类的bytecode，defineClass。 其他反序列化链使用URLClassLoader进行远程加载类。 JNDI远程加载类。 所以想到： 我们能否写单个类，让它能够触发时，使用2的思路去寻找request和response