上次网络抖动,发现一系列的问题,其中之一就跟这个保活定时器有关。

业务描述:
提供的服务为主备模式,调用方仅会访问主服务,备服务仅在主服务挂掉的情况自动切换以提供服务,平时无访问。

问题描述:
当网络出现抖动时,一段时间主服务不可达,备服务升为主服务提供服务。但到原主服务上看时,发现所有的网络连接还都在,但在客户机上已经完全没有对这个原主服务的任何连接。

- 阅读剩余部分 -

前几天处理了一个比较诡异的问题,一直没时间整理,今天简单总结一下。
业务实现概述:
业务在启动时连接zk并创建EPHEMERAL_SEQUENTIAL模式的结点
[code]
/**
* The znode will be deleted upon the client's disconnect, and its name
* will be appended with a monotonically increasing number.
*/
EPHEMERAL_SEQUENTIAL (3, true, true);
[/code]
同时对其所在的目录加watcher,当watcher监听到Expired事件时,重连并检验当前结点在zk中的状态,没有则创建之。
[code]
/** The serving cluster has expired this session. The ZooKeeper
* client connection (the session) is no longer valid. You must
* create a new client connection (instantiate a new ZooKeeper
* instance) if you with to access the ensemble. */
Expired (-112);
[/code]

问题描述:
网络抖动后,业务连接zk正常,却未建立相应的结点。结果是:此业务等于是被下线了,出现问题。

- 阅读剩余部分 -

今天有同事碰到问题,打在jar包中的spring配置文件无法加载,后发现是上下文配置成了:classpath:spring/*.xml
改成classpath*:spring/*.xml后搞定。

在csdn中看到多篇文章,这么解释的:
[code]
classpath*:的出现是为了从多个jar文件中加载相同的文件.
classpath:只能加载找到的第一个文件.
[/code]

感觉不是太可靠,简单翻了一下源码,在PathMatchingResourcePatternResolver中可以一探究竟。

- 阅读剩余部分 -

最近在搞的一个项目,在Android 4.4(API 19)下,gzip会崩溃。
相关的调用代码如下:
[code]
ByteArrayOutputStream baos = new ByteArrayOutputStream();
GZIPOutputStream gos = null;
try {
gos = new GZIPOutputStream(baos);
gos.write(srcData);
gos.finish();
gos.flush();//这里会崩溃
} catch (IOException e) {
e.printStackTrace();
} finally {
gos.close();
}
[/code]
崩溃时的日志如下:
[code]
11-25 15:33:13.757: E/AndroidRuntime(10723): FATAL EXCEPTION
11-25 15:33:13.757: E/AndroidRuntime(10723): Process: com.xxxxx, PID: 10723
11-25 15:33:13.757: E/AndroidRuntime(10723): java.util.zip.DataFormatException: stream error
11-25 15:33:13.757: E/AndroidRuntime(10723): at java.util.zip.Deflater.deflateImpl(Native Method)
11-25 15:33:13.757: E/AndroidRuntime(10723): at java.util.zip.Deflater.deflateImpl(Deflater.java:241)
11-25 15:33:13.757: E/AndroidRuntime(10723): at java.util.zip.Deflater.deflate(Deflater.java:232)
11-25 15:33:13.757: E/AndroidRuntime(10723): at java.util.zip.DeflaterOutputStream.flush(DeflaterOutputStream.java:193)
11-25 15:33:13.757: E/AndroidRuntime(10723): at com.xxxxx.xx.Xxx.compress(Xxx.java:727)
...此处略去N行无关信息
11-25 15:33:13.757: E/AndroidRuntime(10723): at android.os.Handler.dispatchMessage(Handler.java:102)
11-25 15:33:13.757: E/AndroidRuntime(10723): at android.os.Looper.loop(Looper.java:137)
11-25 15:33:13.757: E/AndroidRuntime(10723): at android.os.HandlerThread.run(HandlerThread.java:61)
[/code]

- 阅读剩余部分 -

忘记是哪位大仙的说法,记忆中一直是maven依赖树中存在同一jar的多版本时,会自动依赖最新版本。

今天查找项目依赖时,发现在二级依赖中同时存在两个版本,maven引入的却是老版本。

翻了一下官方文档,只说是依赖于最近的版本。实测发现,同级中存在多个版本时,先依赖哪个版本就用哪个版本。

最靠谱的方法,就是直接依赖最新版本,也就是最近的依赖,会覆盖掉子级的低版本依赖。

- 阅读剩余部分 -