自定义博客皮肤VIP专享

*博客头图：

点击选择上传的图片

格式为PNG、JPG，宽度*高度大于1920*100像素，不超过2MB，主视觉建议放在右侧，请参照线上博客头图

请上传大于1920*100像素的图片！

博客底图：

点击选择上传的图片

图片格式为PNG、JPG，不超过1MB，可上下左右平铺至整个背景

栏目图：

点击选择上传的图片

图片格式为PNG、JPG，图片宽度*高度为300*38像素，不超过0.5MB

主标题颜色：

RGB颜色，例如：#AFAFAF

Hover：

RGB颜色，例如：#AFAFAF

副标题颜色：

RGB颜色，例如：#AFAFAF

预览取消提交

自定义博客皮肤

-+

上一步保存

IT进行时的专栏

技术的使命在于创造价值

05月 04月 03月 02月

Netty + Protobuf 的客户端模式运用和问题探讨

使用NETTY之前，当然需要先看一下所带的samples。简单的hello world，可能大家都没啥感觉，觉得NETTY其实很简单： 1. 对于服务器端，需要写下面几个：a. 写个ServerHandler，来接收并处理服务端业务逻辑；b. 照葫芦画瓢整个Pineline，比如ServerPipelineFactory，把一些现成的和自己的ServerHandler...

2012-05-14 16:04:01 158

原创实战：使用JMeter的Java Sampler轻松定制自己的benchmark

以前碰到更多的是WEB APP的性能测试，也许用得最多的是Loadrunner， Web Stress tool之类的常态化工具，从没考虑过对于后端引擎类的测试是怎样的。现在有幸主导了一个企业引擎的研发，其最关健的不是其功能如何，而是性能如何。故benchmark就显得尤为重要。既然是benchmark，一系列的性能监测、度量工具使用在所难免： 1. nmon。首选的AIX

2012-05-06 22:25:11 6133

实战：使用JMeter的Java Sampler轻松定制自己的benchmark

以前碰到更多的是WEB APP的性能测试，也许用得最多的是Loadrunner， Web Stress tool之类的常态化工具，从没考虑过对于后端引擎类的测试是怎样的。现在有幸主导了一个企业引擎的研发，其最关健的不是其功能如何，而是性能如何。故benchmark就显得尤为重要。既然是benchmark，一系列的性能监测、度量工具使用在所难免： 1. nmon。首选的A...

2012-05-06 22:08:14 288

20种工作流模式（Workflow Patterns）——大牛Aalst的作品

包括如下模式的详细介绍 Basic Control Patterns Sequence Parallel Split Synchronization Exclusive Choice Simple Merge ADVANCED BRANCHING AND SYNCHRONIZATION PATTERNS Multiple Choice Synchronizing Merge Multi-merge Discriminator N-out-of-M-join STRUCTURAL PATTERNS Arbitrary Cycles[自由循环] Implicit Termination PATTERNS INVOLVING MULTIPLE INSTANCES MI without synchronization MI with a priori known design time knowledge MI with a priori known runtime knowledge MI with no a priori runtime knowledge STATE-BASED PATTERNS Deferred Choice Interleaved Parallel Routing Milestone CANCELLATION PATTERNS Cancel Activity Cancel Case

2009-08-12

现有Working Copy如何与SVN库关联起来？

2010-01-23

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

itstarting CSDN认证博客专家 CSDN认证企业博客

码龄23年

IP 属地：新加坡

IP属地以运营商信息为准，境内显示到省（区、市），境外显示到国家（地区）

18: 原创

47万+: 周排名

159万+: 总排名

2万+: 访问

: 等级

430: 积分

2: 粉丝

2: 获赞

7: 评论

1: 收藏

私信

关注

热门文章

分类专栏

最新评论

工作流引擎是否应该建立在有限状态机（Finite State Machine, FSM）引擎之上？
shuishouhcd: 让我开眼界了，之前弄工作流就知道 jbpm,activities 也知道二者的流程设计语言 bpmn。这个wfmc还是第一次听说。不清楚 jbpm,activities 是否满足 wfmc 规范。我也认为fsm能够用来做wfmc的事情，尤其是复杂多变的审批流程操作。
Apache Cassandra Learning Step by Step (5): 实战性的JTwissandra项目
itstarting: 引用「第一个问题，我暂时采用了方案一，土办法。因为对于方案二而言：1. Super CF根本解决不了问题；...」 POST UPDATE: 其作者Patricio Echague建议使用MicrosecondsSyncClock，而非MicrosecondsClockResolution。其原理也很简单：如果一个毫秒内大于一次以上调用，第二次开始，每次调用在long类型的timestamp上加1 参考讨论：https://groups.google.com/forum/?fromgroups#!topic/hector-users/IfABWOh0HLg 所以最后的代码是： [code=java] /** * REF: * 1. FAQ * http://wiki.apache.org/cassandra/FAQ#working_with_timeuuid_in_java * 2. DISCUSSION: * https://groups.google.com/forum/?fromgroups#!topic/hector-users/IfABWOh0HLg * * @return UUID */ public UUID getUUID(){ ClockResolution clock = new MicrosecondsSyncClockResolution(); return TimeUUIDUtils.getTimeUUID(clock); } [/code]
Apache Cassandra Learning Step by Step (5): 实战性的JTwissandra项目
itstarting: 第一个问题，我暂时采用了方案一，土办法。因为对于方案二而言：1. Super CF根本解决不了问题；2. Super CF是一种有争议的概念，很可能会被废掉下面是第二个问题：我发现uuid会重复，导致循环调用addTweet后的实际tweet数量，少于预期的数量(e.g. 100次循环，预期产生100个tweet，而实际上只有不到90个）。为什么？因为如果是相同的tweet_uuid的话，就算用mutator.addInsertion，一样会replace掉（好比RDBMS的update）这块涉及的问题代码是： [code=java] /** * REF: http://wiki.apache.org/cassandra/FAQ#working_with_timeuuid_in_java * * @return UUID */ public UUID getUUID(){ //TODO: which UUID should we use to make sure it's unique? ClockResolution clock = new MicrosecondsClockResolution(); return TimeUUIDUtils.getTimeUUID(clock); //return TimeUUIDUtils.getUniqueTimeUUIDinMillis(); } [/code] 从我引用的讨论和作者Patricio Echague的说法来看，如果一个毫秒内可能产生多次调用的话，建议用TimeUUIDUtils.getTimeUUID(clock)。然而结果不是这样的，为什么？待解，打算直接跟作者沟通一下，可能是用法不当
Apache Cassandra Learning Step by Step (5): 实战性的JTwissandra项目
itstarting: 第一个问题发现在getTweets里： [code=java] public List<Tweet> getTweets(List<String> tweet_uuids){ MultigetSliceQuery<String, String, String> multigetSlicesQuery = HFactory.createMultigetSliceQuery(KEYSPACE, SERIALIZER_STRING, SERIALIZER_STRING, SERIALIZER_STRING); multigetSlicesQuery.setColumnFamily(CF_TWEET); multigetSlicesQuery.setColumnNames("user_uuid","tweet_content"); multigetSlicesQuery.setKeys(tweet_uuids); QueryResult<Rows<String, String, String>> results = multigetSlicesQuery.execute(); return convertRowsToTweets(results.get()); } [/code] 该问题是：如果通过MultigetSliceQuery.setKeys(Iterable<String> keys)传入系列key以进行批量的slice query，其结果并不依赖于keys的顺序，而是依赖于所在CF的建模。也就是说，通过CF_TIMELINE找到了漂亮的排序良好的tweet uuid，如果要获得同样排序良好的tweet列表，必须： 1. 一个一个的找，比如使用ColumnQuery，然后add到结果列表去； 2. CF_TWEET也要考虑通过timestamp来进行Column的排序——跟CF_TIMELINE一样方案一的做法感觉不怎么可取：这意味着需要跟Cassandra交互次数，瞬间X10倍方案二需要考虑一下，从感觉上来看，Super CF再说难免——这个需要进一步验证一下
Jetspeed2 Security
Swestheiyun: 相当不错的帖子，收获很大，谢谢

最新文章

提示

确定要删除当前文章？

取消删除