服务器上发现批量运行状态查询有时会报系统未知错误,然后查询日志发现,batch端返回的rejcode=null,导致mweb无法识别错误类型。
但是为什么rejcode会等于null呢?
跟踪代码发现,batchtemplate里面有一个try catch,在catch里面会给rejcode重新赋值,所以验证try里面的代码
try {
context.setData("_RequestJnlNo", context.getData("_MCHJnlNo"));
context.setData("_ResponseRejCode", "000000");
context.setData("_ResponseSystemId", "Batch");
context.setData("_JnlState", JobState.Finish);
super.execute(context);
} catch (Throwable t) {
context.setData("_JnlState", JobState.Failure);
if (t instanceof PeException) {
context.setData("_ResponseRejCode", ((PeException) t).getMessageKey());
String msg = t.getMessage();
try {
msg = context.getMessageSource().getMessage(((PeException) t).getMessageKey(), ((PeException) t).getArgs(), context.getLocale());
} catch (Throwable t1) {
log.error("getmessage_failed", t1);
}
context.setData("_ResponseRejMsg", msg);
}
发现只有execute报空指针错误才能将rejcode赋值为null
跟踪发现super.execute执行的是JobStatusQryAction
在这个action里面有两个地方有可能会引起空指针,所以增加日志
if (jobId != null && jobId.length() > 0) {
log.info("jobId验证通过:" +jobId);
Job job = this.getJobManager().getJob(jobId);
log.info("job验证通过:" +job);
if (job == null || !job.getRunKey().equals(jobKey)) {
JobRuntimeData jrd = this.getJobManager().getJobRuntimeData(jobKey, jobId);
jobLogList.add(jrd);
} else {
jobList.add(job);
}
} else {
jobLogList = this.getJobManager().getJobRuntimeDataes(jobKey);
log.info("jobLogList验证通过:" +jobLogList);
jobList = this.getJobManager().getJobs();
log.info("jobList验证通过:" +jobList);
if (jobList != null){
for (Iterator jt = jobList.iterator(); jt.hasNext();) {
Job jm = jt.next();
if (!jm.getRunKey().equals(jobKey)) {
jt.remove();
}
else {
for (Iterator it = jobLogList.iterator(); it.hasNext();) {
JobRuntimeData tm = it.next();
if (tm.getId().equals(jm.getId())) {
it.remove();
break;
}
}
}
}
}
}
context.setData("JobList", jobList);
context.setData("JobLogList", jobLogList);
}
发现此处标红代码会引起空指针。为什么这里会空指针呢?
经排查发现是由于batch处理并发时,效率太低,引起死循环,导致此处remove为空
private Map jobMap = new HashMap();// 已初始化未完成的批量
private Map jobMap = new ConcurrentHashMap();// 已初始化未完成的批量
将此处HashMap改为ConcurrentHashMap
为什么此处不能用HashMap?因为HashMap线程不安全,在多线程环境下,使用Hashmap进行put操作会引起死循环,导致CPU利用率接近100%,所以在并发情况下不能使用HashMap。
以下来自网上摘抄:
效率低下的HashTable容器
HashTable容器使用synchronized来保证线程安全,但在线程竞争激烈的情况下HashTable的效率非常低下。因为当一个线程访问HashTable的同步方法时,其他线程访问HashTable的同步方法时,可能会进入阻塞或轮询状态。如线程1使用put进行添加元素,线程2不但不能使用put方法添加元素,并且也不能使用get方法来获取元素,所以竞争越激烈效率越低。
ConcurrentHashMap的锁分段技术
HashTable容器在竞争激烈的并发环境下表现出效率低下的原因,是因为所有访问HashTable的线程都必须竞争同一把锁,那假如容器里有多把锁,每一把锁用于锁容器其中一部分数据,那么当多线程访问容器里不同数据段的数据时,线程间就不会存在锁竞争,从而可以有效的提高并发访问效率,这就是ConcurrentHashMap所使用的锁分段技术,首先将数据分成一段一段的存储,然后给每一段数据配一把锁,当一个线程占用锁访问其中一个段数据的时候,其他段的数据也能被其他线程访问。
大致意思就是:ConcurrentHashMap将数据分段存储,并对每段数据都分配了一把锁,这样线程就有多条路,也不会在一条路上堵塞,引起崩溃。
另外在解决这个问题的时候发现MANIFEST.MF文件里面有一个很有意思的参数
CSII-AutoStart: true //如果为ture则PE部署平台的普通用户可以在batch的包列表里面可见,默认为false 只有管理员sysadmin用户可见
CSII-StartLevel: 8 //包启动级别,级别低的启动优先。