Fan's blog

一般说，消息队列是改进系统伸缩性的选择。一则消息是异步的，二则这会降低系统的耦合度。东西是好东西，有人说jms或者mdb是j2ee规范中最好的标准，不过最近项目中用到的JMS感觉却很痛苦。配置很痛苦，调用很痛苦，调试也很痛苦。感觉这东西是上古的东西，在java中使用很麻烦。

最近看到twitter的架构居然也用MQ，很感兴趣。看了下，跟IBM MQ Server完全不一样，笑。这个原来是基于Memcached协议的一个list，放在内存中，主要强调性能，也可以cluster。调用么，rest style，get/set，标准的东西，对客户端没啥要求，不需要额外包，更不需要预先配置，一个URL搞定。看看这里，觉得也不复杂。

twitter很多东西都是开源了，活雷锋。MQ的这个东西在这里，称为kestrel。基于jdk6 + scala，actor的并发模式，有人已经走读过了。Cool!

相对企业MQ，这东西局限在：1）消息难做到严格的排序；2）事务。大多数情况下不是致命。

多数情况下，如果一个技术上手容易，虽然功能少点，但是也会尝试的在系统中使用。如果跟IBM MQ Server一样的巨无霸，碰的人不多，推广开也难了。

最近在考虑做一个手机上的“可同步的“的记事本，因为感觉的android上的通讯录和邮件功能确实很cool，在PC上面修改Gmail的通讯录马上就可以同步到手机上，这样手机丢了或者刷机后，同步一下就可以了：信息只存在一个地方（这让我想起了TDD中的消除重复…）。

如果记事本里面的内容保存在网络上，在普通的pc上也可以编辑，那么势必还有一整套的相关事情：1）得有记事本的web界面，主要在PC上使用；2）如何说服用户使用这个网站，没有人愿意把私有数据放到一个不知名的网站或者不知道哪里的“云”上；3）还得有 firefox的插件，方便操作；4）如何避免滑入一个信息孤岛，如何和其他app分享数据。

结论是：手机只是网络的延伸，只是PC机不在时的一个补充（或者说当我们不在cloud中时）。PC机上好的应用，可以迁移到这个平台上来，反之则不大可能的。

当然这只是一个例子，只是技术上的可行性验证，不用考虑太多。

如果没有源代码，分析问题就不能追本溯源，就会流于表面。
虽然自己不一定会从头到尾的看代码，但是有源代码在那里，让人总觉得有安全感。

代码的开源，还表示了一种“授之以鱼，不如授之以渔”的态度。源代码提供了更多的信息，提供了解决问题的方式。虽然功能不是最强大的，而自有的产品更多的只是关于配置相关的文档，其后的原理一般人不甚了了。Dan Farion谈及MySpace架构时说到：“我们尝试了某个东西之后就从中学到些东西，然后可能就会把其中有价值的地方给剥离出来，再为了达到我们的性能或伸缩性需求重新写一个。” Open Source则可以充当学习的例子。项目中总会有让人感到棘手的问题，这些问题超出了框架之外，是不能用常规方法解决的，如果而源代码这个时候就能作为特例中的一般例子，让我们有一个改进的基础。

How let your changed java code updated to server? It is a big problem in develpping any non-trivial JEE project.

Resently, I run a JBoss 4.04 outside of Eclipse. The application archive(EAR) is so big that we can not run it in IDE environment. Then the debug process is boring. After having modify the java code, I have to package it, copy to deploy directory and restart the server. Ant can help me a lot but a debug round still takes me much of time.

In this situation, JPDA will useful. With the help of eclipse, I can use it to connect to a “Remote Java Application”. You can find it in “Debug” dialog. Then you can inspect value of a varible and even modify the java code. Before that, you have to add a breakpoint to your java code. Only java with breakpoint can be modified and replaced to the server. This is a nice feature when you need modify code many times. When eclipse has attached remote server, any modified java code could be updated to the server. This is so-called “Hotswap Bug Fixing”. Of course the source code should be added to the debug instance’s “Source lookup path“. Otherwise the server didn’t suspend at your breakpoint. And you should mind that the compiled classes were swapped just in the server’s memory and didn’t updated to the server’s file system. So after finished debug, you should copy the classes to the server’s deploy directory.

Some other approaches I often used include Hot deploy and restart application (not server).

Hot deploy is used to deploy a archive such as .war or .jar(EJB) automatically when you put them in deploy directory. Most servers has this feature.

Restart application or Reload Context is used to reload all resource(classes and configuration) in one application eg EJB, or War. This approach is heavier than others. Tomcat will throw exception “Out of memory” after reloaded a web application many times.

To Netbeans, It provides debug mode also. There are some differences on “hot class replace” between it and eclipse.

Above is netbeans 6M10 debug tool bar. It has a “Apply Code Changes” button to submit the changed code to server. It need you do manually. This way is different from eclipse which done automatically.