服务器接收不到腾讯开放平台的发货回调请求

最近在协助其他组做腾讯平台接入的相关工作,开发蓝钻包月营销活动。虽然两年前我自己的项目已经接入过了,本以为驾轻就熟,没想到还是踩到了一些坑。最大的blocking issue是发货回调地址不生效,也就是发货服务器接收不到腾讯的请求,请求进不来都无法调试了,真是急死人了。最后问题还是解决了,总结下有以下几个原因:
1.平台的缓存问题,但是请注意这个是你最后应该考虑的,因为开平后台发货地址改动的生效时间不会超过5分钟。
2.浏览器缓存
3.前后端API参数是否符合文档要求!仔细核对每一个参数,他们的值,类型等一定要符合官方文档的要求。我们这次接入就是因为一个重要的参数-分区ID:zoneid传错了。前端把这个参数写成了int型,而文档要求的却是字符串类型,从而导致开平后台收不到这个参数,所以没有回调。
4.搞清楚现网环境还是沙箱环境。正常情况下,如果你采用的腾讯云服务器地址是测试地址(119.147.19.43)的话就是沙箱环境,反之就是现网环境。但是有一个例外,就是在测试充值蓝/黄钻会员时,需要修改本机的host使他指向测试地址(这样调试就不用扣真正的Q币了)。在这种模式下虽然服[……]

继续阅读

Eclipse离线安装反编译插件(Eclipse Class Decompiler)

之前只用了IntelliJ IDEA一段很短的时间,但对他自带的反编译功能却念念不忘,简直是阅读源码大杀器,太方便了。在又切回eclipse之后就不习惯了,于是强烈地想找到一款eclipse反编译插件。搜了搜,好像比较流行的就这一款插件,作者还是个中国人,点个赞。作者的博客明确指出从某个版本开始就不支持离线下载了,但我经常用的eclipse却在公司内网,那怎么办呢?之前在学校的时候装eclipse的插件好像就是plugins和feature文件夹下面放几个jar包就行了,但如今eclipse的版本已经更新太多了,还能不能行呢?试一下就知道了。
首先在外网的Eclipse Marketplace安装一下这个插件:https://marketplace.eclipse.org/content/eclipse-class-decompiler ,安装好了之后在plugins和feature分别找到以”org.sf.feeling.decompiler”开头的文件或者文件夹,然后把这些拷贝到内网相同的目录下面,重启eclipse就大功告成。
文件结构大概是这样的:
plugins文件夹:[……]

继续阅读

对NIO的几点理解

一、基本概念
Blocking IO VS NonBlocking IO
阻塞IO:线程会一直等待/阻塞直到IO操作完成,比如准备读取10个字节的数据,但是现在只读了8个,那么当前线程会一直等下去,直到读取到剩下的2个字节的数据。这是普通IO的线程模型:
bio-png
非阻塞IO:在进行IO操作时线程并不会阻塞(等待),一次只读取能读取的数据,读完立刻返回,然后线程会去继续处理其他事情。等下次可读的时候被唤醒,再来读取数据。这是NIO的线程模型:
nio-png
因此在阻塞IO模式下,如果你要处理N个请求的话,就需要开启N个线程分别处理这些请求。因此最大的连接数取决于服务器能开出的最大线程数,虽然后期采用线程池的方式做了些优化,但总体而言性能并没有很大提升。而在非阻塞IO下只要一个线程就够了,不断的在各个连接之间切换,在某个连接有可用事件的时候通知主线程。
咋一看是不是很容易理解?但是对于NIO的工作模式我一直有个疑问:

主线程立即返回了,那读写数据的时候总得消耗线程吧?

其实真正的IO操作是内核线程,但上层也需要用户线程去调用。而且NIO所说的用户线程立刻返回并不是说不消耗线程,而[……]

继续阅读

java进程coredump(二)

上篇介绍了如何生成一个Java进程的coredump,今天则来总结下当Java进程挂掉之后应该怎么样一步一步来分析。

一、Fatal Error Log
接着昨天的例子继续看,在coredump之后目录里面的文件是这样的:

一般情况下当Java进程挂掉之后,在程序目录下面会生成一个错误日志:hs_err_pidxxxx.log。这个文件是你排查问题的过程中第一个应该阅读的日志,因为这个文件里面会记录很多有用的信息,比如:线程堆栈,堆的使用情况,JVM参数和环境变量,虚拟机状态,操作系统信息等。这里提供的信息非常多,也非常全面,为我们大致定位问题提供了很大的帮助。
先来看下文件开头的注释信息,这里的信息很粗略地指出了崩溃的原因:

第8,9行指出了出现问题的栈是在动态库crash.so的Java_CoreDumpTest_crash方法。接下来看下具体的堆栈信息:

继续阅读

java进程coredump(一)

上篇文章介绍了coredump的基本知识以及gdb调试core文件的相关操作,这篇文章主要介绍如何生成Java进程的coredump,也就是说如何写一段java代码使它被操作系统kill掉。我们都知道因为jvm的存在,java层面的代码无论你怎么写都是不太可能crash的,顶多是OOM或者stackoverflow,然而这些都会被jvm捕捉并抛出异常,而不是被操作系统直接kill掉。所以如果一个java进程crash掉,那肯定是挂在native code上了(当然JVM本身的bug就另说了),因此思路就是通过java的JNI(java native interface)调用本地方法,使进程挂掉。具体步骤如下:

1.编写java代码,调用本地方法

2.编译,生成.class文件

3.生成头文件:CoreDumpTest.h

该文件的内容如下:
[cr[……]

继续阅读