- 博客(10)
- 收藏
- 关注
转载 Kerberos的原理
这是MIT(Massachusetts Institute of Technology)为了帮助人们理解Kerberos的原理而写的一篇对话集。里面有两个虚构的人物:Athena和Euripides,通过Athena不断的构思和Euripides不断的寻找其中的漏洞,使大家明白了Kerberos协议的原理。 Athena: 雅典娜,智慧与技艺的女神。 Euripides:欧里庇得斯, 希腊的悲
2006-09-08 14:19:00
2893
1
原创 java之内存泄漏
内存泄漏的问题也是老生常谈的问题。C++由于内存的分配和回收都是由程序员自己管理的,coding的时候小心些,出现内存泄漏的几率就会很小。而java由于使用了GC,由GC自动去回收无用的内存,内存的管理似乎变得很简单。但是,如果不知道GC的工作原理,一旦出现内存泄漏的问题,就十分头痛了;即使知道了GC的工作原理,解决内存泄漏也是一件繁琐的工作。当然,了解GC的基本工作原理,对解决内存泄漏
2006-04-17 02:36:00
3097
1
原创 Java NIO是否到处都适合?
为了实现高性能的MOM(消息中间件),学习了java的NIO,想利用NIO技术来改善网络通讯的性能。学习NIO的时候,看了书上的,也找了网上相当多的资源,但大部分的资料都是比较粗浅的,入门级,深入的基本没有。不过,对于了解和学习NIO来说已经足够了。真正的领会还是需要在实践中获得的。 NIO的技术在JDK1.4中出现。NIO最大的特点有两个:一个是块状读写;另外一个是多路
2006-03-19 18:46:00
4854
7
原创 流量控制器+消息cache实现高性能稳定的MQ服务器
本来想把MQ的消息cache改造过程详细写写,由于到年关了,项目要验收了,时间紧得很,只好把新的想法写下来,原来的改造想法就先搁着吧,等有空了再说(估计是不会有空的了)。 消息cache对MQ性能的影响是不必说了,肯定是导致MQ性能下降的一个重大原因。既然不能抛弃它,那就好好利用它。如果能在资源宽裕的情况下不使用消息cache,保持MQ的性能;而只有在资源吃紧的情况下
2006-01-17 23:55:00
4920
4
原创 消息cache,我真得需要你吗(2)?
本来写blog的时候并没有想到会有多少人看到,所以,只是把所想的写下来。后来,发现有很多热心的人给我的问题提了很多意见,心里很是感激。想想同仁的意见如果可以帮我改进JTangMQ的设计,那真得是求之不得的事情,亦或是我写的东西对其他人也有参考价值,那是我的莫大荣幸了。那就继续把所想的写下来吧。 上篇提到,消息cache引出的两个问题令人十分头痛,它的的确确影响着JTan
2006-01-15 00:31:00
2318
2
原创 消息cache,我真得需要你吗(1)?
由于JTangMQ提供的消息服务是异步的服务,消息的发送者和接收者可以不需要时刻在线或同时在线,也不需要知道彼此的身份,发送者和接收者只需要同MQ的服务器进行交互。因此,在实际应用中可能会出现两种场景:一是消息的发送者和接收者同时在线并分别不断进行收发操作。此时,对于服务器来说有一个消息接收流量和消息发送流量,如果消息接收流量大于消息发送流量,则服务器上的消息数就会越来越多,最终将
2006-01-12 00:24:00
3965
5
原创 JTangMQ的现在和未来
原本打算今天只是想写写JTangMQ接下来的改造计划,正思考着,接到吴健老师打来的电话,需要我提供一些JTangMQ的相关资料,那就干脆写一下JTangMQ的目前的情况以及将来的改造思路。 消息中间件的出现大概已经快有七八的历史了(具体什么时间开始还没考证)。起初的时候,各个厂家由于没有统一的标准,也出于企业的private的目的,各个消息产品都有自己的api和架构,彼此之间并不相容。
2006-01-08 00:16:00
3422
1
原创 线程的上下文开销真得那么厉害吗(2)?
线程切换的开销的确是比较厉害的。这是从今天的实验中得出的结果。 为了解决上次提出的疑问,今天在实验室做了一个试验,来测试线程的切换是否开销比较大。由于主要是为了比较线程的数目多少对性能的影响,所以,具体的测试环境就不提了,只要每次实验在同等的条件下即可。 首先,在MQ的Server端启动100个读线程,100个写线程,100个消息deliver线程,客户端同
2006-01-07 23:04:00
10531
9
原创 线程的上下文开销真得那么厉害吗(1)?
终究还是郁闷着了,为了JTangMQ的性能。 都是因为MQ,这个令人又爱又恨的家伙。想起当初刚刚开始设计JTangMQ的豪言壮志,为MQ设计、coding的三百多个日夜历历在目,如今却坐在椅子上一声叹息。为何JTangMQ的性能还是那么不尽如人意?为什么呢? 最初的设计目标是“超过国产MQ,迈向SonicMQ”,而现在的产品同JBossMQ相比还有那么一点的差距。这个差距
2006-01-07 00:11:00
7813
18
原创 JTangMQ开发历史
2004年11月 J2EE应用服务器立项,阅读JMS规范12月 收集关于JMS的OpenSource和现有的MQ产品 2005年1月 确定分析JBossMQ,UberMQ和OpenJMS的源码3月 总结和汇报源码分析成果,并开始对JBossMQ,WebloigMQ,SonicMQ等的测试4月 命名J2EE应用服务器为JTang,JMS实现为J
2005-07-21 00:27:00
2671
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人