超时

1、客户端的js处理(使用jqury) <script type="text/javascript"> //<![CDATA[ $(document).ajaxComplete(function(event, xhr, settings) { if(xhr.getResponseHeader("sessionstatus")=="timeOut"){ if(xhr.getResponseHeader("loginPath")){ window.location.replace(xhr.getResponseHeader("loginPath")); }else{ alert("Request time out relogin plase !"); } } }); //]]> </script> 2、服务器端处理(filter中) if(sessionTimeOut){ //判断是否为ajax请求 if (httpRequest.getHeader("x-requested-with") != null && httpRequest.getHeader("x-requested-with").equalsIgnoreCase("XMLHttpRequest")) { HttpServletResponse httpResponse = (HttpServletResponse

dubbo超时异常 在调用dubbo服务时经常看到如下错误： Caused by: com.alibaba.dubbo.remoting.TimeoutException: Waiting server-side response timeout by scan timer. 源码分析 客户端调用远程服务时，本地会生成一个DefaultFuture，调用DefaultFuture.get()获取远程服务返回的结构,此方法获取锁，调用await方法，此时当前线程进入等待队列，此线程会有两种结果过：要么超时，抛出TimeOutException；如果被唤醒，则返回rpc的结果。 而这里的报错很明显是由于等待服务端返回结果时客户端超时异常，查看源码如下： public class DefaultFuture implements ResponseFuture { private static final Logger logger = LoggerFactory.getLogger(DefaultFuture.class); private static final Map<Long, Channel> CHANNELS = new ConcurrentHashMap<Long, Channel>(); private static final Map<Long,

本文同步至 http://www.waylau.com/netty-time-out-and-heartbeat/ 本文介绍了 Netty 超时机制的原理，以及如何在连接闲置时发送一个心跳来维持连接。 Netty 超时机制的介绍 Netty 的超时类型 IdleState 主要分为： ALL_IDLE : 一段时间内没有数据接收或者发送 READER_IDLE ： 一段时间内没有数据接收 WRITER_IDLE ： 一段时间内没有数据发送 在 Netty 的 timeout 包下，主要类有： IdleStateEvent ： 超时的事件 IdleStateHandler ： 超时状态处理 ReadTimeoutHandler ： 读超时状态处理 WriteTimeoutHandler ： 写超时状态处理 其中 IdleStateHandler 包含了读\写超时状态处理，比如 private static final int READ_IDEL_TIME_OUT = 4; // 读超时 private static final int WRITE_IDEL_TIME_OUT = 5;// 写超时 private static final int ALL_IDEL_TIME_OUT = 7; // 所有超时 new IdleStateHandler(READ_IDEL_TIME_OUT

net.http 包中的超时设置 服务端 app.Server.ReadTimeout app.Server.WriteTimeout 是针对所有请求设置的选项 默认 net.http keepalived 开启，超时时间为 3 分钟，如下 1942 type tcpKeepAliveListener struct { 1943 *net.TCPListener 1944 } 1945 1946 func (ln tcpKeepAliveListener) Accept() (c net.Conn, err error) { 1947 tc, err := ln.AcceptTCP() 1948 if err != nil { 1949 return 1950 } 1951 tc.SetKeepAlive(true) 1952 tc.SetKeepAlivePeriod(3 * time.Minute) 1953 return tc, nil 1954 } 没看到保活超时的配置选项，生产环境可以禁掉 针对每一连接，设置超时，可以参考 http://grokbase.com/t/gg/golang-nuts/12czccncw7/go-nuts-net-http-server-readtimeout-and-keep-alive-interaction 客户端 刚才看了下

想必大家在用MySQL时都会遇到连接超时的问题，如下图所示： 就是这个异常 (com.mysql.jdbc.exceptions.jdbc4.CommunicationsException:Communications link failure Last packet sent to the server was X ms ago)，是由于MySQL服务在长时间不连接之后断开了，断开之后的首次请求会抛出这个异常。那么既然是连接超时的问题，就要去MySQL中探究一下连 接时间是怎么控制的。打开MySQL的控制台，运行:show variables like ‘%timeout%’，查看和连接时间有关的MySQL系统变量，得到如下结果： 其中wait_timeout就是负责超时控制的变量，其时间为长度为28800s，就是8个小时，那么就是说MySQL的服务会在操作间隔8小时后断 开，需要再次重连。也有用户在URL中使用jdbc.url=jdbc:mysql://localhost:3306 /nd?autoReconnect=true来使得连接自动恢复，当然了，这是可以的，不过是MySQL4及其以下版本适用。MySQL5中已经无效 了，必须调整系统变量来控制了。MySQL5手册中对两个变量有如下的说明： interactive_timeout：服务器关闭交互式连接前等待活动的秒数

作者: Laruence ( ) 本文地址: http://www.laruence.com/2014/01/21/2939.html 最近我们的服务在升级php使用的libcurl, 期望新版本的libcurl支持毫秒级的超时, 从而可以更加精细的控制后端的接口超时, 从而提高整体响应时间. 但是, 我们却发现, 在我们的CentOS服务器上, 当你设置了小于1000ms的超时以后, curl不会发起任何请求, 而直接返回超时错误(Timeout reached 28). 原来, 这里面有一个坑, CURL默认的, 在Linux系统上, 如果使用了系统标准的DNS解析, 则会使用SIGALARM来提供控制域名解析超时的功能, 但是SIGALARM不支持小于1s的超时, 于是在libcurl 7.28.1的代码中(注意中文注释行): int Curl_resolv_timeout(struct connectdata *conn, const char *hostname, int port, struct Curl_dns_entry **entry, long timeoutms) { ....... ....... #ifdef USE_ALARM_TIMEOUT if(data->set.no_signal) /* Ignore the timeout when

最近用到了HttpClient写爬虫，可能我有新版本强迫症，老是喜欢用新版本的东西(虽说新版本不一定好用),然后就用了HttpClient 4.3。HttpClient这货和Lucene一样，每个版本的API都变化很大，这有点让人头疼。就好比创建一个HttpClient对象吧，每一个版本的都不一样， 3.X是这样的 HttpClient httpClient=new DefaultHttpClient(); 4.3是这样的 CloseableHttpClient httpClient = HttpClients.createDefault(); 当然，上面这些变化只不过是一些小变化，大家看看API大家就都会了。 我要讲的是超时设置,HttpClient有三种超时设置，最近比较忙，没时间具体归纳总结，以后再补上，我这里就讲一些最简单最易用的超时设置方法。 这是个3.X的超时设置方法 HttpClient client = new HttpClient(); client.setConnectionTimeout(30000); client.setTimeout(30000); HttpClient httpClient= new HttpClient(); httpClient.getHttpConnectionManager().getParams()

在Mysql的默认设置中，如果一个数据库连接超过8小时没有使用（闲置8小时，即28800s），mysql server将主动断开这条连接。 在运维监控系统中，程序会报如下异常： <!-- lang: java --> org.springframework.orm.hibernate3.HibernateJdbcException: JDBC exception on Hibernate data access; nested exception is org.hibernate.exception.GenericJDBCException: could not inspect JDBC autocommit mode 底层错误日志： <!-- lang: java --> [130925-102435-381][ERROR][ActionQueue:afterTransactionCompletion 179]could not release a cache lock org.hibernate.cache.CacheException: java.lang.IllegalStateException: The org.hibernate.cache.UpdateTimestampsCache Cache is not alive. at org.hibernate.cache

在web开发中，通常会有session超时处理，对于普通的http请求比较容易处理，而对于ajax异步请求，可能就需要特殊处理了 /* 服务器端：拦截器或过滤器处理：*/ // 异步请求session超时的处理 if (request.getHeader("x-requested-with") != null && request.getHeader("x-requested-with").equalsIgnoreCase("XMLHttpRequest")) { PrintWriter wirter = response.getWriter(); wirter.write("timeout"); wirter.flush(); } else { // 普通http请求session超时的处理 return Action.LOGIN; } /* 浏览器端：JQuery添加全局AJAX默认选项：complete回调函数：*/ $.ajaxSetup({ global: false, type: "POST", complete: function (XMLHttpRequest, textStatus) { var data = XMLHttpRequest.responseText; if (data == "timeout") { if( window.top != window

1.低效操作产生的延迟。单命令操作一半很快不会造成这样，SORT,LREM, SUNION，keys ，＊ 等操作都会影响响应时间。 使用进程监控程序（top, htop, prstat, 等...）来快速查看Redis进程的CPU使用率。如果traffic不高而CPU占用很高，八成说明有慢操作。(top -p pid) slowlog 查询引发延迟的慢命令：(默认超过10毫秒就算慢命令) 只针对慢命令进行统计 slowly get 10 查看前十条慢命令 config get slowlog-log-slower-than 设置慢命令时间（默认10000us） 10ms 2.客户端连接数量，默认为10000 ，超过5000就会影响性能 3.客户端连接数的限制 4.加强内存管理 5.命令处理总数的影响：total_commands_processed 6.延迟命令查询： 文中出现的延迟（latency）均指从客户端发出一条命令到客户端接受到该命令的反馈所用的最长响应时间 redis-cli --latency -h host -p port 7.网络和通信引起的延迟 当用户连接到Redis通过TCP/IP连接或Unix域连接，千兆网络的典型延迟大概200us，而Unix域socket可能低到30us。这完全基于你的网络和系统硬件。在通信本身之上，系统增加了更多的延迟（线程调度