最近一段时间，发现gae上request的cpu占用明显的多了，cpu占用的配合比之以前增加了好几倍。看后台的日志，大量的request持续了较长的时间，占用了异常多的cpu。这些request都报出了

“com.google.appengine.repackaged.com.google.common.base.FinalizableReferenceQueue <init>: Failed to start reference finalizer thread. Reference cleanup will only occur when new references are created.”

这样的异常。Gae 开发者解释说这个异常抛出是正常的，原因是Gae是不允许起后台的线程的；GAE捕获了这个异常并输出到INFO级别，并且，理论上这个异常也不会对性能产生影响。

但是为什么异常出现的request，耗时都特别长呢？原来这个异常通常是出现在GAE重新加载你的web应用的时候。也就是说，这种request到来的时候，GAE启动了一个新的web container！这个过程是很耗时的，需要load很多相关的class。现在看来，当第一个请求进来的时候，GAE会起一个container来加载应用，这个instance会持续一定的时间，如果在这段时间有新的的请求，就由这个instance来处理了。如果一段时间内(这个时间现在貌似在2分钟左右)没有新的request到来，GAE就会关掉你的web server销毁这个instance。当这个instance销毁之后，一个新的request到来，就又会启动新的instance了。google 最近应该是对这方面的策略做了一些改动，或许是生存时间之类的参数变短了，总之现在大量的请求到来的时候需要新的instance，导致耗费了大量的CPU和较慢的响应。

java还是太重了，不适合这种速生速死的应用方式。GAE的技术人员已经声称会改善这个问题；自己写个cron job每一分钟去访问自己的服务也可以极大的减少web应用重启的次数。另外，减少jar包依赖对于减少重启时间也是有帮助的。

这又是一篇技术文，同时也是一篇牢骚文，正常人类可以跳过了。

GAE最近发布了1.30版本，提供了Blobstore功能。GAE是不允许写文件的，Datastore中提供的存储服务每条记录最多只能存储1M的记录，而Blobstore可以提供最大50M的文件存储。同时GAE也提供了用于处理文件上传/下载的handler，只要在上传文件的form表单中指定upload的url就行了，BlobstoreService会自动处理上传请求，存储文件及文件的类型和信息，并返回文件记录的key。

这个功能对于GAE残次的文件功能算是聊胜于无吧，看到更新后兴奋了一下，决定动手把原来的的文件上传迁过去了；然后，很悲剧的发现，现在这个功能只向付费用户开放！

Blobstore用不了就折腾点别的。原想做个发文自动推送到qq空间的功能，因为qqzone现在是支持email发文的，所以想通过邮件这条路来做。要动手才发现google和腾讯真是一对残次品，GAE发邮件只支持使用自己的smtp服务器，qq空间只接受qq邮箱smtp server发送的文章。直接走肯定是通不了了，难道要gae先发送到QQ邮箱，QQ邮箱再自动转发到qqzone里吗……

然后又看了下豆瓣的开发API，决定折腾这个。豆瓣是个技术狂热型的公司，这从他们使用python语言，以及提供开放API，以及API走gdata协议都可以看出来。但是他们的java API client再次让我郁闷了。这么个小的API client，竟然依赖那么多jar包，jar爆炸就是你们这种人造成的！好吧，依赖gdata这些还情有可原，依赖httpclient你是唱的哪处戏啊！httpclient这种，3.x到4.x一升级API全变……并且使用还很广泛，别的项目如果已经用了4.x的jar包，你豆瓣的API client何以自处，根本就放不进去了嘛。你看看你家老师Google的java API client，什么时候使用过httpclient。

回到老话题上，最悲剧的是GAE根本就不支持httpclient……又是一对残次品。悲剧的后果是没法用豆瓣的API client，直接上体力活去解析人家很高级的gdata数据。

结论：GAE现在根本不是云，也就算是一片小水雾。

我的blog开放了匿名评论以后，一直以来都挺平静的，没有垃圾评论，多半因为它本来看的人就不多……但是前端时间不晓得是哪里的谁忽然看上它了，spam扑面而来。国庆前两天就有苗头了，但我直接把垃圾评论删了了事，也没在意。回家待了几天回来，已经上白天spamming信息了。

所以我终于决定要解决一下GAE上的验证码问题了。本来生成验证码是件挺简单的事，JDK就有把文字打到图片中的方法；而且还富有大量第三方的Captcha库，能生成各式各样的验证码，诸如背景带斑点的，文字扭曲的，英文的，汉字的，机器看不懂人也看不懂的……一应俱全。但是悲剧的GAE啊！作为谷歌一直鼓吹的云，连一点点图片io操作都不支持，所有和图片相关的jdk接口全上了它的blacklist！

真是恨GAE不成钢啊。无奈之下决定山寨到底，自己从头动手：

1. 开个矩阵存放图片每个像素的RGB值，自己手动在RGB矩阵里划出数字和字符来……由于字符实在太多就只画了10个阿拉伯数字，而且横平竖直的像老式电子表中的数字
2. 写个纯java的图片编码工具，把RGB值矩阵编码成gif或者png格式的byte流，写到response里。

山寨是山寨了点，不过总算是整出来了，对付一般的小蟊贼够用了。

Google 应用系统引擎最初是以 Apache Tomcat 作为其 webserver/servlet 容器的，但最终将切换到 Jetty 上。这个决定让许多开发人员都诧异的想问：为什么要做这样的改变?Tomcat 有什么问题吗? 我们获得的一次访问 Webtide ——Jetty 背后的公司——里的这个团队的机会，得到了关于这个决定背后更详细的信息。

记者： 为什么Google选择Jetty作为其应用系统的引擎，而不是 Tomcat 或其他的?

Google选择Jetty的关键原因是它的体积和灵活性。 在云计算里，体积的因素是很重要，如果你运行几万个Jetty的实例(Google就是这样干的)，每个server省1兆，那就会省10几个G的内存(或能够给其他应用提供更多的内存)。

Jetty 被设计成了可插拔和可扩展的特性，这样Google就可以高度的自定义它。 他们在其中替换了他们自己的HTTP connector，Google认证，以及他们自己的session集群。也真是奇怪，这个特性对于云计算来说是非常出色的，但同时也让Jetty非常适合嵌入小的设备中，例如手机和机顶盒。

记者： 是什么促使Jetty成为Java里出色的servlet容器?

我们在开发Jetty时，并没有想着要把它开发成一个全功能的应用server(尽管它是的)。每一项功能都考虑了可插拔性，所以，如果你不需要他，你就可以不把它加载到内存里，把它从request 处理调用链中去掉。如果你不需要sessons，你可以把session处理器拿掉，这样你就不要浪费资源去来回寻找session cookie了。当你每秒钟都有出来上千个请求时，这些微小的查找动作的开销是非常的大的。

我们也并没有想当然的企图通过设计就可以得到最优化的代码，我们是如同收集沙粒般，每次得到一些人告诉我们如何才能有好的JVMs优化和垃圾回收办法。这是真的，已经很小心的代码仍然能被优化，最后的效果就是避免创建新的对象。例如，我们在Jetty里使用并行处理技术，但我们并没有使用很多标准的并行处理数据结构，因为这需要创建太多的对象。所以，只是作为个例子，我们使用了双并行锁循环 arrays，而不是采用并行链式 lists，这样我们就能够在不创建对象的情况下，获得了非阻塞并行效果。

记者： 是什么使Jetty成为开发人员的一个有用的server平台的(例如：testing)?

Jetty 已经在一些流行框架中内置了，例如GWT，scala/lift，grails，Jruby等等，还有很多。如果你使用了这些技术，你就直接可以用 Jetty了。 Jetty-maven 插件是另外一个非常优秀的开发工具，它能让web应用在不打包成war文件的情况下运行。源文件可以直接编辑，在不需要把它重新放进war文件的情况下获得测试结果。 Jetty嵌入式的特征让我们不再需要写通过写那些main方法、通过你的IDE，调试器或 profiler 来运行之类的无聊的事情。

记者： Jetty在处理 client-server 请求时有什么独特的地方吗?

Jetty 现在是一个第二代的异步处理server。过去的两年里，我们让Jetty实现了处理异步请求的功能，这成了它核心架构的一部分。就像其他的支持异步 serlets容器一样，我想，他们会发现这个东西并不是看起来的那么简单和容易。 我们的异步HTTP引擎被我们复用在了HTTP client 上，所以我们可以大量的降低request 和 responses 消耗。

同时，就像我之前提到过的，我们的请求处理器是可扩展和可插拔的，这让web application可以被单独省略掉，或者是单独使用，或者是进一步扩展的application。

记者： 有没有其他Jetty使用的案例，大的或小的?

使用Jetty的公司有像Zimbra/Yahoo，这意味着Jetty正作为web mail 服务器，为百万级的用户提供服务。 Eclipse IDE把它内置了进去，这意味着有成百万的开发者在桌面运行Jetty。 Jetty被 hadoop map/reduce cluster使用，在其上有几千个点的集群，处理着世界最大的TB级别的数据分类排序工作。 我们也有 J2ME 的接口，有本地编译器，所以我们可以在手机上，家用路由器和 Java cards 上运行。 更多的Jetty使用的例子可以参考 http://docs.codehaus.org/display/JETTY/Jetty+Powered

记者： Jetty的将来或蓝图是怎样的?

Jetty 最近的计划是发布 7.0.0 版本，这将会完全的迁移到eclipse foundation 下。 Jetty 7 将会支持很多 servlet 3.0 的特征，但是并不会使用新的API 和 不会依赖Java 1.6 。 Jetty 7后，很快我们会发布Jetty 8，这将会完全支持 servlet 3.0 和 Java 1.6，Jetty 会继续的创新 和跟踪各种web 2.0 里的其他的新成果。我们现在已经能支持 Firefox 3.5 里的跨域Ajax功能，我们可以在cometd版本里使用这个。我们很快就会增加对 WebSocket 和 BWTP 的支持。 对 Google wave 以及相关协议的支持的问题已经优先排到了我们的议事日程上了。

记者： Google/Jetty 还有其他的计划吗?

Google有他们自己下棋的棋局，我们并不清楚。 我们在JavaOne大会上曾经和App Engine开发者们有个简单的对话，我们愿意听他们任何的反馈和意见，用来改进Jetty的可嵌入性和可扩展性。

下面的跟Webtide团队的讨论中，我们询问了SpringSource 从Jetty转换到Tomcat的事情。

记者： 你们如何看待 SpringSource 把 Grails 从本来作为缺省容器的Jetty换成了Tomcat的事情?

原因是grails开发的领导感觉使用Tomcat能从内部的Tomcat开发人员哪里获得更好的”服务“。我猜测，他们把Grails的用户驱赶到某一个平台，以让SpringSource能更好的销售他们的技术支持服务。几年前我们看到了相同的事情，JBoss 雇佣了一下tomcat开发人员后把Jetty提出成了Tomcat，并最终和Mort Bay达成了商业合同。很遗憾，这些商业协议对技术选择有如此大的影响，当相同的是，一些基础结构的工程也正聚集到也application server 为中心的队伍里来。

Grails将会继续同时支持对Jetty和Tomcat的集成，但会改成Tomcat为缺省服务。

这看起来是 SpringSource使用/攀附 Tomcat 的一个特别合适的论断。
新闻来自:读译网

Google app engine限制实在太多，用来写blog还行，想要商用简直是痴人说梦。能想像一个连生成验证码这样的功能都不可能支持的host么，能想像一个不能上传文件，request/response都有莫名奇妙的时间限制，数据库查询只能有有一个不等条的host么？就现在的功能来说说，GAE也只能做个玩具，指望这个跟Amazon EC2、MS Azure拼那是完全没戏的。

应该说，GAE终于支持java了。java在开源社区和厂商都有广泛的支持，有众多开源的框架、库可供使用。使用java语言的人数是使用python语言的N倍！

点击http://appengine.google.com/promo/java_runtime申请GAE for java！

Google App Engine现在开放注册了。每人可以创建三个application ，每个application 可以免费拥有500M空间，以及足够支持每月500W次PV的cpu时间。对于个人来说，这已经足够使用了。

Google App Engine目前只能使用python，可以使用python的大部分标准库，在将来可能加入对其他语言的支持。

下面是我的GAE application，用了水木上一个人写得简单的blog。
http://xine.appspot.com/