前几天处理了一个比较诡异的问题,一直没时间整理,今天简单总结一下。
业务实现概述:
业务在启动时连接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引入的却是老版本。

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

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

- 阅读剩余部分 -

以root用户登录从库,执行:
show slave status\G
两个关键指标如下:
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
这两个值都是Yes,代表从库的从步已经起动,如果为No,执行以下命令启动:
slave start;

还有一个从库延迟的关键指标:
Seconds_Behind_Master
如果值为0,代表无延迟。大于0时,值越大,延迟越厉害。

- 阅读剩余部分 -