Jie 的个人资料Sunset (hhj's public hom...照片日志列表更多  |  工具 帮助 |
|
2008/10/31 月底总结用两个字总结本月，那就是充实。如果描写的详细一点，那就是眉头紧锁，咬牙切齿的从牙缝里挤出几个字：“充实，太TMD充实了”。首先是忙。做项目是很有意思的事情不假，但确实也挺累的。我又不是工作狂，所以有点怨言应该也在所难免。不过也只是一点点怨言而已，其实总的来说还是有意思的成分占大部。那么为啥做这个表情呢，倒不是因为恨，而是因为这个月真的是太充实了。 从月初说起吧。注册的事情，合同的事情，工作许可的事情，几经反复，真有点大起大落的感觉。具体的故事就不说了，反正跟我熟的人都已经知道了。不过好在现在事情都结了，身份问题也算有了着落，所以就不说了。剩下的时间主要就是做项目了。不过项目的具体情况我就更不想说了。倒不是因为郁闷或者别的什么事，主要是因为工作日志都写在MSN Space上，很详细，我就懒得重复了。有兴趣的朋友自己去看吧，不过估计也没几个人真有兴趣，呵呵。 既然正事都不想说，就说点乱七八糟的事吧。我也懒得建什么逻辑结构了，以下就全用Bullete Points（谁能告诉我中文该怎么说？必有重谢）吧。 * 今年新的博士生似乎比以往多不少，是因为经济危机吗？工作不好找了于是就更倾向于读博士了？原因是我胡猜的，不过这条事实应该是准确的。 * 学生卡没了，拿着临时卡在食堂吃饭都不打折。不打就不打吧，售货员还经常忍不住好心问我为啥没有学生卡。虽然知道他们是好心，但老得花时间解释也挺烦的——肚子饿，受不了啊。后来我就直接把临时卡拿出来说我就是一Vistor，能不能打折您看着办吧。这样的确快不少，但是也有心特善的，拿着我的临时卡刷好多次，自然没用（我说了，不过她不信），她还不罢休，跑去问主管为什么这卡用不了……不过也有运气好的时候。有一次我说我没卡，那个售货员直接问排在我后面人说能不能把你的学生卡借来用一下，我正纳闷这是要干啥呢，她用那人的卡刷了，然后语重心长的跟我说，你看，这样不就便宜多了，下次记得带卡啊。看来还是装新生小正太比较有前途。 * 二楼那个便宜又好吃（相对的！）的食堂居然没了，改成了一个又贵又难吃的自助，真郁闷。不过校园小报Felix上已经连续两次批评这个举措了，也许过段时间能改回来吧？盼望中…… * 买了1~3区的地铁月卡，一算发现自己几乎在亏的边缘上。月卡是109 GBP，如果一天乘一个来回那就是22~24天的钱。也就是说我只要一个工作日不去学校就亏了。遂决定一定要养成以实验室为家的好习惯。要做到每周保证来五天，争取来六天，偶尔来七天，每天至少待10小时，认真工作，认真学习。我在此，向祖国和人民发誓：如果我做不到，我就对不起领导，对不起党，对不起人民，我就不配做一个中华人民共和国的公民……得，这又岔到相声（《十点钟开始》，好段子啊！）上去了。 * 找到了传说中的特拉法加广场里那些“不要喂鸽子，因为它们已经越来越讨厌了”的牌子。看来这事是真的。可惜啦，小时候一直想来看看这个著名的鸽子广场，结果等我来了，鸽子不见了…… * “居里夫妇一块在实验室里废寝忘食的提纯镭真是世界上最浪漫的事”——居然这样‘BT’的论断都有人认同，大好大好。不过也借此认识到了囚徒困境（Prisoner Dilemma）的普遍性。另外也以实践证明了一个巨弱智的解决囚徒困境的方法——信息交换，然后就从多均衡退化到单均衡了（某人大吼：靠，这是玩赖！）。 * 参加了一堂助教培训课，发现批作业原来比我想象的辛苦多了。终于认识到了我去年把要求两页的报告写到十页是一件多么可恶的事情。下学期也许就要做这活了，又不多给钱。虽然不太想花这工夫，但是心想自己从写作业的人‘升级’成了批作业的人，也挺爽的。 * 实践再次证明，计划永远是完不成的。预计一个星期的活做了两个多星期，还是在紧赶慢赶的情况下。 * 发现居然有人（白人）姓Westgate，这不是‘西门’么！真是牛X的姓氏。如果有人叫Snowdrift Westgate那就更好玩了[Tang F., 2008]。 * 把9月买的几个高达模型做了，过两天上图。不过我手艺不好，做的很烂，到时别拍我砖就是了。 * 最后，关于上篇日志。相信因为这个我已经彻底被一些人看扁了——虽然留言里面没有反映。不过话说回来，你要是BS某人还会去留言吗？关于那篇纯发泄我也没啥可解释的，反正熟悉我的人都知道故事的来龙去脉，也知道我是个啥人，那就成了。 * 最后的最后，我似乎又有了争取以后去美国玩几年的动力。大好大好。 LOG_2008_10_31Here are some thoughts on how to further improve our own framework.
First of all, a small issue is that we may change the function interfaces a little bit in order to achieve consistency in usage of pointers and references. Overloaded functions may be added for this purpose in order to replace the default argument value mechanism which we are using now.
Secondly, we may change the the PublsihMessage function to better guarantee communication reliability. Note that the reliable message delivery is not always guaranteed in our framework. In particular, message transmission could be failed if there does not have enough space for the message in receiver's inbox at the moment. This could happen in two situations. In that first case, the message is larger than the size of the receicer's inbox. Here, it is simply impossible to put the message in anyway and thus specifying a larger inbox size would be the only solution. But in the second case, where the receiver's inbox is sufficienctly large but still can not hold the newly published message because of lack of of free space, our current implementation would simply return FALSE to indicate failure, which is not the best approach. An improvement is to wait for a while until the receiver's Inbox Monitoring Thread retrieves some old messages to eventially free enough space for the newly arrieved one. Of course, a timeout value should be applied as well to avoid infinite wait in certain circumstances (e.g. when clushes with client log-off / unsubscription).
Finally, we also give some considerations to message re-sending. Here are many ways to do this. One possible solution is to create a pivate channel for each client, and thus P2P communication could be implemented. This requires no change to current framework architecture but may not be that straightforward to developers. Another solution is to embed this P2P communication supports directly into our framework's SDK. The second method may be more welcomed by developers but would in turn require significant extensison to current design of the framework. More consideration regarding to this issue is still needed before we make our final decision.
Finally, despite this is another night in lab for me, I would still wish a Happy Halloween to those who are lucky enough to enjoy their life better. 2008/10/30 Comparison between ActiveMQ and our own frameworkComparison between ActiveMQ and our own framework ******************** Conceptual Comparison ******************** | ActiveMQ | Our Own Framework [Note 1] An ActiveMQ-based system often consists of a number of modules, which are implemented as standalone EXEs, and a message broker, which acts as the system manager and message dispatcher. Since ActiveMQ is an (extended) implementation to JMS [URL 1], both Publish / Subscribe (P/S) and Peer-to-Peer (P2P) communications are supported [URL 2]. Here, ActiveMQ's implementation to P2P communication is quite interesting. In its implementation, messages are not directly sent to the receiver but to a broker-managed entity called a 'Queue'. To retrieve messages, the receiver should subscribe to the queue, just like subscribing to Topics (equivalent to Channels in our framework) in P/S domain. As we can see, this scenario is very similar to P/S communication. Nonetheless, there do have some differences. First of all, unlike Topics, a Queue can only have up to one receiver at any time. Secondly, a Queue maintains a buffer to hold received (by the Queue) messages if it has no subscriber at the moment [Note 4]. These buffered messages would be sent to any new subscriber immediately after its subscription. By contrast, messages sent to a Topic with no subscriber are simply destroyed in no time. ActiveMQ's 'strange' implementation to the P2P communication eliminates the necessity of having ID for all clients (but ID can be still assigned), which is an interesting fact. Ideally, only Queues and Topics have ID, as they are called Destinations, and this is already sufficient for establishing any forms of message communication within the system. The interface of the P/S communication domain in ActiveMQ is very similar to that in out own framework. However, their underlying implementations are significantly different from each other. In ActiveMQ, C/S architecture is exploited. Namely, each client establishes and maintains a TCP connection to the broker (server) at all time, which is used to delivery data messages. When a message is published, it would be firstly sent to the broker and then dispatched to all subscribers with respect to the subscription information, all through these TCP connections. Although our own framework also requires the establishment of TCP connections between clients and the server, they are only used to delivery system management message. Data messages are always delivered in a P2P manner through the specially designed Shared Memory based protocol in our framework. Conceptually, it is expected that ActiveMQ's TCP based implementation should be far less efficient (in terms of maximum data throughput and resource consumption level) than our Shared Memory based method. Moreover, ActiveMQ's C/S architecture would also concentrate the pressure of the broker when during with concurrent communications. [Note 2] Dynamic configuration means we do not have a static configuration file for the system, which can be load and parsed by some manager and enable user or developer to start the entire system in a single command. Instead, we hard code pieces of subscription information into each module's own programme implementation, and manually start them one by one in execution. Comparing to the other method (static configuration), static configuration is less convenient but yet more flexible. [Note 3] In the most extreme case, messages would be saved into disk file and are guaranteed to be delivered even in situations when broker itself crashes. However, this is the most inefficient case. By contrast, the developers can totally cancel the reliability guarantee mechanism in order to achieve higher efficiency. A number of parameters have been introduced to enable developers to better balance between reliability and performance. [URL 3] gives a detailed description to all these parameters. In the following quantitative tests, the default configuration, which is also used by ActiveMQ-CPP's example programme, is used for it best fits into our requirement in communication reliability. [Note 4] This mechanism will cause the sender to wait infinitely if it keeps sending messages after the Queue's buffer is already piled full. ******************** Quatitative Comparison ******************** In order to derive quantitative comparison results in terms of data throughput, message delay and resource consumption level, two test programmes have been developed. One uses ActiveMQ while the other exploits our own framework. In each of the test programme, a message receiver and a message publisher are implemented. The message publisher continuously does the following in a worker thread: {Publish a message; Sleep 10 ms}. Here, length of the published message is configurable and the sleep operation is used to avoid 'busy waiting' when the message length is short. In the mean time, data rate, average message delay is calculated and displayed by the receiver. Note that because message publication takes time, the packet rate can never reach 100 P/s. The long it takes, the lower the packet rate is. In addition to the quantitative results, I have also added '* High CPU Usage' tag to some rows to indicate that the overall CPU consumption at these situations are over 50% (obviously can not be tolerated in real application). The tests were running on a ThinkPad T43 laptop computer, with 2.0 GHz Intel Pentium M processor and 1.0 GB of physical memory. 1. ActiveMQ 1.1 Send to a Queue Message Size Data Rate Average Delay Packet Rate 1 KB 83 KB/s 1.06 ms 83.00 P/s 1.2 Send to a Topic (1 Subscriber) Message Size Data Rate Average Delay Packet Rate 1 KB 82 KB/s 1.04 ms 82.00 P/s 1.3 Send to a Topic (3 Subscribers) Message Size Data Rate Average Delay Packet Rate 1 KB 75 KB/s 2.00 ms 75.00 P/s 2. First Example Framework 2.1 Send to a Channel (1 Subscriber) Message Size Data Rate Average Delay Packet Rate 1 KB 93 KB/s 0.02 ms 93.00 P/s 2.2 Send to a Channel (3 Subscribers) Message Size Data Rate Average Delay Packet Rate 1 KB 91 KB/s 0.04 ms 91.00 P/s From these results, the following points can be discovered: 1. When using ActiveMQ, sending messages to a queue yields similar performance to sending messages to a topic with 1 subscriber. 2. Message delay in our own framework is less than 1/10 of that in ActiveMQ in all circumstances. 3. ActiveMQ can only support concurrent data communication up to about 6 MB/s in total, which is far less than 170 MB/s maximum throughput in our own framework. 4. Note that ActiveMQ's capacity is insufficient for delivering video streams, which normally consists of 25 MB-level messages per second. ******************** Conclusion ******************** From this study, we see ActiveMQ is aimed at generality rather efficiency. Namely, ActiveMQ can be used in many languages and on many operating systems. In addition, both P/S and P2P communications are supported by ActiveMQ, with various level of reliability enforcement policy. Nonetheless, the quantitative comparison results suggest ActiveMQ's performance in terms of message delay, data throughput and resource consumption level is much poorer than that of our own framework. The most important point is that ActiveMQ's capacity is insufficient for delivery real-time video streams, which would vital in our applications, and hence do not fulfill our requirement. Moreover, the fact that ActiveMQ-CPP is not BUG free (memory leak is detected) and difficulty in configuration of the development environment are additional reasons that why we should favour our own framework over ActiveMQ. ******************** References ******************** [URL 1] JMS Tutorial, [URL 2] JMS Tutorial - Basic JMS API Concepts, [URL 3] Configuring ActiveMQ-CPP, [URL 4] CMS API and ActiveMQ-CPP API, [URL 5] Apache ActiveMQ, LOG_2008_10_29In the previous weeks, I have been developing test programmes for producing quatitative comparison results between ActiveMQ and our own framework. Data throughput, message delay and resource consumption levels were the main concerns. In the mean time, I have also read more documentation about ActiveMQ, which are firstly summarised below. Here are some finding about ActiveMQ from my literature study: 1. ActiveMQ always (at least for ActiveMQ-CPP clients) use TCP to deliver data between clients and the broker. Therefore, it is expected that ActiveMQ's performance, in terms of data throughput and resource consumption, should be worse than that of our own framework's. This is because our framework takes advantage of Shared Memory, which has been prooved to be much more efficient than TCP when all communicating peers are running on the same host. 2. One advantage of ActiveMQ is that it supports various level of reliability gurantee. In the most strict case, all messages would be saved into disk files and thus message lost are effectively avoided even if broker is crashed (or terminated). However, this is also the most inefficient case due to the extra operations incurred. By default, ordered reliable transmission is only guranteed within each single session of the broker. Additionally, if message lost is tolerated in certain circumstance, relaxation can be made by using difference parameter (tag) combinations which in turn yields better performance. Exhaustive evaluation to all parameter combination is virtually impossible. Hence, the default setting, which best fits into our need, is used in all of our tests. Afterall, since we constantly require reliable message delivery, ActiveMQ's added fexibility in this issue is not really that useful to us.
In order to get quatitative results, two test programmes have been developed, which use ActiveMQ-CPP and our own framework's SDK, repectively. In both of them, we have implemented a receiver and a publisher. The publisher simply does the following in a worker thread: /* Pseudo Code */ Here, dwMessageLength is a variable which can be specified by users from the GUI. The published messages are received by the receiver. Several indicators, including data rate, message rate, average delay, are then calculated and displayed. Test results are shown in the following tables: 1. ActiveMQ 1.1 Send to a Queue Message Size Data Rate Average Delay Packet Rate 1 KB 83 KB/s 1.06 ms 83.00 P/s 1.2 Send to a Topic (1 Subscriber) Message Size Data Rate Average Delay Packet Rate 1 KB 82 KB/s 1.04 ms 82.00 P/s 1.3 Send to a Topic (3 Subscribers) Message Size Data Rate Average Delay Packet Rate 1 KB 75 KB/s 2.00 ms 75.00 P/s 2. First Example Framework 2.1 Send to a Channel (1 Subscriber) Message Size Data Rate Average Delay Packet Rate 1 KB 93 KB/s 0.02 ms 93.00 P/s 2.2 Send to a Channel (3 Subscribers) Message Size Data Rate Average Delay Packet Rate 1 KB 91 KB/s 0.04 ms 91.00 P/s From these results, the following points can be discovered: 1. When using ActiveMQ, sending messages to a queue yields similar performance to sending messages to a topic with 1 subscriber. 2. Message delay in our own framework is less than 1/10 of that in ActiveMQ in all circumstances. 3. ActiveMQ can only support concurrent data communication up to about 6 MB/s in total, which is far less than 170 MB/s maximum throughput of our own framework. 4. Note that ActiveMQ's capacity is insufficient for delivering video streams, which normally consists of 25 MB-level messages per second. Up till now, the conclusion should be obvious enough. In consideration of the significant performance gap, we have strong reason to favour our own framework over ActiveMQ. 2008/10/16 LOG_2008_10_16The work continued during these two days. The compilation has succeeded on Tuesday but there is still a problem: the built activemq-cpp.lib is ridiculously large, namely, around 300 MB. This is certainly unacceptable and thus we have to do something. The first idea came into my mind is to build a DLL version of everything: if that activemq-cpp thing must be this large, at least a DLL version would give us much smaller EXEs. So I tried again to see if we can build everything into DLL. Well, this is not a short story but I'll just focus on the result. Luckily, it finally worked and a functional DLL version was produced at last. Better than this, the size of the produced activemq-cpp.dll is at a reasonable level, say, about several MBs. But don't ask me why... Alas, finally this painfully long journey of building the SDK came to an end and I can give a conclusion here. How to make ActiveMQ and ActiveMQ-CPP work on your own machine. *Tip* Before starting anything, you should firstly make sure you have sufficient free disk space. To give you an idea, it cost me 1.04 GB on my computer. 1. Download ActiveMQ, ActiveMQ and Apache Portable Runtime (APR). You may also download CppUnit as well, but that is not really required. Among them, both source code package and binary distribution of ActiveMQ are available online. Of course, I would recommend you to use the binrary distribution. For other things, only source code version is available, so you don't have options any more. In addition, because ActiveMQ is built in Java, JDK is required. To run ActiveMQ's provided Java example, something called ANT is also needed. *Tip* Unless specifically mentioned (like 'to build XXX, you need X.Y.Z version of PPP'), always download the latest official release version of every package mentioned above. Otherwise, you may encounter misterious errors as I had experienced. 2. Alright, so you have everything now, let's begin to make them running. First, install JDK and ANT. JDK has a InstallShield and thus installing it is quit easy. To install ANT, just follow its online mannual, which is not difficult to follow. You just need to decompress the package and set some environment variables. At this moment, you have the basic environment established. 3. To install ActiveMQ, simple decompress the downloaded package and it shoud then work. Nonetheless, it is never a bad idea to toy it a little bit. So, start a cmd, cd into ActiveMQ_Home\bin, and run 'ActiveMQ.bat'. Your firewall may give you a prompt saying something is requesting to access the network, allow it, and you'll see large portion of text flow down that cmd window, which indicates the ActiveMQ broker is running now. Otherwise, you'll see error messages if some error occurs. After starting the borker, start two new cmd windows, cd into ActiveMQ_Home\examples, then execute command 'ant consumer' and 'ant producer' respectively. If things are going well, you'll see messages beeing produced and consumed. To terminate the broker, just use Ctrl+C. There is no 'more graceful' way. 4. If your ActiveMQ does work, you can start to build ActiveMQ-CPP now, which is the real hard piece. First, you need to build APR, which consists of three packages, apr, apr-iconv and apr-util (yes, you have to download all of them). Decompress them into the same parent directory, and name the decompressed folders to 'apr', 'apr-iconv' and 'apr-util'. This is very important as this directory tree will be used in the building process. Now, go to apr-util, you'll see a dsw file called 'aprutil.dsw'. Although there are also dsw files in apr and apr-iconv, the one contained in apr-util subsumes them. Open it, but not with VC6 but VS2005. Because that ActiveMQ-CPP package only provides an VS2005 sln file, you'd better build the APR in VS2005 as well to avoid potential version incompatibility problems. After converting and openning that dsw file, you'll see a lot of projects. you DON'T need to build all of them. Instead, only libapr, libaprionv and libaprutil are required. To build them, set active configuration to ReleaseDLL, right click on libaprutil and choose 'build this project only'. The preset dependency tree will automatically cause libapr, libapriconv and other required components to be built in the same time. The building process may take some time so just be patient. Warnings may be generated but you can safely ignore them. When the building process completes, you'll see Release folders are generated in apr, apr-iconv and apr-util. libapr-1.lib/dll, libapriconv-1.lib/dll and libaprutil-1.lib/dll can then be found in these Release folders. These files, as well as all header files in the Include folders, are all you need to continue your work. You may also want to have a Debug version of them by changing active configuration to DebugDLL and do the whole thing again. 5. At last, the final step is to build the ActiveMQ-CPP. Decompress the downloaded package, go to ActiveMQ-CPP_Home\vs2005-build and click that sln file to open the workspace. 4 projects are presented. Again, you don't neet to build all of them, only activemq-cpp and activemq-cpp-example (the first two projects) are needed. This time, you need to change the project options a little bit before building. First, add apr, apriconv and aprutil's Include directory to the project's 'additinal include directories' setting. Then, make both of these two projects to link against all libs you have generated in step 4. Finally, change active configuration to ReleaseDLL and use the similar trick to sperately build activemq-cpp and activemq-cpp-example. Again, the building process is quite time consuming. The final ouput, namely, activemq-cpp.lib/dll and activemq-cpp-example.exe will be placed in vs2005-build rather than the generated Release folder. To do a test, run the ActiveMQ broker, then start the compiled exe file and you'll see 2000 messages being produced and consumed. Obviously, all dlls we generated so far are required to start that exe. 6. After the building process, you may want to copy all necessary files out to form a 'clean' SDK package. Here is all you need: libapr-1.lib/dll, libapriconv-1.lib/dll, activemq-cpp.lib/dll, Include folders from apr, apr-iconv and apr-utils and all .h files found inside ActiveMQ-CPP_Home\src\main. Note that the folder structure of all these header files should be preserved as it is maybe required by files. This 'clean' SDK is 16.2 MB in size on my computer. And finally, we are done. After completing the entire building process, I then started to write a small test programme to extract some key figures of ActiveMQ, including its maximum data throughput, message delay and so on. However, since the programme is still under development, I don't have much to say at current stage. P.S: Why I also need to prepare the Refs? Damn it! Oh, I also need to give Maja an coarse working plan regarding to the framework issue 2008/10/14 LOG_2008_10_14I continued my evaluation today. First, I tried to make a consistent compilations of all the stuffs (say, all DLL or all LIB). The results show that DLL version can not be created for APR-ICONV and APR-UTIL but 'all LIB configuration' seems working. Then, I tried to start exploring what ActiveMQ really is. Well, ActiveMQ is HUGE. It is an complete implementation of JMS plus many additional features. ActiveMQ is aimed at generality rather than efficiency. As we can see, ActiveMQ supports multiple platforms (Linux, Windows and Mac) and multiple languages (Java, of course, and C++ through CMS and many others. Well, here is an additional comment about the relationship between CMS and ActiveMQ-CPP: CMS is like JMS, which is just an API specification while ActiveMQ-CPP is the actually implementation, which is similar to J2EE). In addition, it supports both queue-based P2P communication and topic-based P/S communication plus a wide range of configuration parameters for both of them. A comprehensive evaluation of all configuration combinations of ActiveMQ is simply impossible within this short period of time. Thus, during my tests, default values are used for most parameters. Moreover, for obvious reason, only the scenario of Windows + CPP clients is studied. To begin the story, let us first get a brief view of how ActiveMQ works. ActiveMQ is something known as a messaging middleware. That is to say, it is used to deliver messages between clients, which could be different objects, threads, processes and so on. Two types of communications are supported. First one is called PTP communication. Here, the system maintains several queues, each one belongs to a specific receiver (a client). When there are messages sent to the queue, they will be subsequently dispatched to (in async case) or retrieved by (in sync case) by the receiver. Note that different from other implementations, queues in ActiveMQ are managed by ActiveMQ rather than the receivers, through each queue should relates to only one receiver and hence is logically belonging to it. Consider e-mail as an example here. The second one is P/S based communication, which we are already very familar with. The P/S scenario in ActiveMQ is very similar to that in Fleeble, only 'channels' are now called 'topics' instead. Moreover, message filtering may be applied before messages are being dispatched hence we also see some charactoristics of Psyclone. Interestingly, clients do not have ID (by default) in both cases. In P/S scenario, ID is certainly not a must. Although ID is seemingly important in PTP communication, separating queues from clients makes this requirement not necessary any more. So, how this whole thing works? Again, like Psyclone, ActiveMQ is implemented as a central server, which is called 'message broker', plus a number of client development SDKs (like CppAIR in Psyclone) for different languages (ActiveMQ-CPP is the one for C++). To make the system runs, developers first need to develop some cliens (mostly as standalone applications), which use the SDK to send or receive (and of course, to process) messages (which are called producers and consumers). Then, we start the broker (simply the one name ActiveMQ) and all the clients, let clients to connect to the broker, creat all topics and queues, make subscriptions and finally the system starts as all communication begin. This is indeed very similar to Psyclone, but some remarkable differences do exist. 1. Static system configuration is not supported: you can not store the system configuration (describing which clients, topics, queues are used and what is the subscription relationship between them) in a file and start the system with a single key stroke. 2. TCP is the only underlying ICP method used by ActiveMQ (Say, it does not take advantage of Shared Memory when clients and the broker are both running on the same computer. Moreover, there is nothing equivalent to 'in-process modules' in Psyclone). Thus, bad performance is expected when dealing with very-high bit-rate data delivery tasks. Well, I have only stated its dark side so far. But what is the advantage of ActiveMQ? Generality! There are really not too many situations where ActiveMQ can not be used. You can use it in PHP, Java, C++ and so on; on Windows, Linux and / or Mac; on localhost or across intranet / internet; using (different types of) PTP and / or P/S communications; integrating with website or not... Nonetheless, Efficiency seems more important to us and thus this great advantage is not really exicting, is it? After the conceptual study, I decided to do some real tests. Guess what, its own example didn't work! Messages are indeed posted (can be seen within the web-console) but never get received. That is indeed wierd. I tried different parameter configurations, went through every relevant help-doc and forum post but I was still stuck there. Finally, after hours of frustration, I found the solution: upgrading the ActiveMQ (which I downloaded in March) to a more recent version (or maybe using a older version of other components would also work)... Nobody has left a single clue to rediculous matter. So, this version incompatibily issue (and painfully lack of formal documentation), is perhaps another conpelling reason that why we should not us ActiveMQ... Now, I finally get the example runs on my machine. I have changed it a little bit to test both PTP communication and P/S one. So far, both of them seem to work as ActiveMQ claimed so. I intended to do more tests to get key figures like latency, throughput, resource consumption level and so on, but it is already this late. So I'll certainly need to allocate another day for this evaluation task. And that is all for today. P.S: Need to write to KQH regarding to my external references, replying to JD. Also need to post to WTG and SYS, and don't forget to ask the librians about cards before meeting with Maja. 2008/10/13 LOG_2008_10_13To follow the regulation, my log book starts running today. All articles with a title started by 'LOG' are automatically categorized into the log book. These articles are for my personal reference only and you are not expected to be interested in them. Nonetheless, considering some of my speculations and observations might be useful to others, I decided to make most of the my logs public. Alright, following is the real content.
Today, I was continuing to evaluate ActiveMQ. Indeed, ActiveMQ supports many languages. Nonetheless, but for obvious reason I only considered the usage involving C++ programming. Although ActiveMQ is, in essense, an implementation of JMS and primarily supports Java, it is still possible to use it in C++ applications. In order to achieve this, an C++ SDK, which is called ActiveMQ-CPP, is provided. This SDK is similar to the Framework SDK I had developed during my MSc project. Though using it, applications would be able to conveniently exploit the whole ActiveMQ stuff (protocol and its implementation) as a communication middleware.
To evaluate the whole thing, we have to firstly set up the environment and a demo system. This is, I am afraid, not a easy task. Doploying ActiveMQ is trivial but ActiveMQ-CPP led to a totally different story. The key is ActiveMQ-CPP only provides source code, which has to be built by ourselves. Adding to this, ActiveMQ-CPP also replies on a number of other SDKs which do not provide compiled binaries either. The dpendency tree is like this:
ActiveMQ-CPP
|--Apache Protable Runtime (APR)--apr-util
|--CppUnit |--apr
|--apr-iconv
|--apr
Lack of documentation and version imcompatibility made the situation even worse. At last, it cost me a whole day only to get all these things compiled! I'll try to make some meaningfull evaluation on these things tomorrow, regarding to their efficiency, resoure consumption level, effectiveness and usability.
And here are some other stuffs: 1. Meeting with Maja at 11:00 am on Wednesday; 2. Got to get a library card ASAP; 3. Got to make a schedule to seperate different tasks. Here is the first draft: Weekdays: 8:30~9:30: reading Metro on the tube; 9:30~6:30: focusing on my PhD / RA related tasks; 6:30~7:30: reading books w.r.t. my personal reading plan; 8:30~11:30: focusing on the website development work. Weekend: Sat.: website development and / or outdoor activities; Sun.: PhD / RA research. This schedule may subject to temporary disruption and further adjustment. 2008/10/6 我的致谢先说句题外话，今天上午答辩很顺利，老Duncan都说impressive，Maja也终于在good前面加了她很少使用的修饰词，我似乎又可以继续幻想一下MSc with Something了。好了，硕士的事情终于结束了。（不用提醒我Queen's Tower...） 又到了学校正式开学的日子，上午看到很多新学生填表注册，中午的食堂也热闹了起来。看到这些脸上写满了好奇和憧憬的新面孔，不由的想到一年前的自己。一年的时间过的果然很快。五门专业课，一门论文学习课，两个小项目，一个毕业设计，这就是硕士课程的全部。虽然项目的结果还不知道（'nonetheless, it is expected to get a high mark' - said Maja)，但是考试考到Top of Class，还‘撞大运’的拿到了一个带Funding的读PhD的机会，这一年怎么着也算是小成功了。 虽然没写到论文的Acknowledgement里，但是我还真想额外谢谢一些人，那些从中学以来在各种场合鄙视我的人们。对，我感谢你们，感谢你们的鄙视。 首先感谢少年班长期以来鄙视我的某些老师们。看吧，多次当着全班的面鄙视我在家不跟老妈练英语（我就是觉得这样很傻难道也有错吗？）并断言我一定混不出名堂的汪老师，老子现在Imperial College London混的比硕士班上绝大多数Home Students还牛那么一点点。看吧，天天中午把我叫到办公室边吃饭边骂的徐老师，老子在书写、古文和修辞方面就是没天赋，但在浙大近十万字的本科毕业论文却是全系最高分，您还能说我‘没有基本的使用语言的能力’吗？看吧，当年在高考前我心理压力最大的时期还鄙视我数学上不了120的张老师，对，我高考数学确实因为您这一句话紧张到发挥失常只考了119，但是老子现在也是Department of Computing天天玩N维向量的博士生了。看吧，当年鄙视我‘完全没有钻研问题的学术精神’的程老师，老子在浙大毕业的时候混到了个‘学术之星’，在中科院工作和在Imperial College读硕士的时候也被认为有很强的Academic Potential，您的慧眼是不是也有看错的时候？程老师啊，当年您以黑箱操作的方式在未经选拔的情况下让某些人获得宝贵的机会然后再不断的用他们的成功事例来鄙视我，您不觉得这样很恶心吗？最近几年，每每在梦中又见到一脸鄙视指着鼻子断言我没前途的诸位恩师们并尖叫着从汗湿的床上惊醒时，我如何能忘却这个畸形的少年班教育！王老师啊，您还建议过我老妈带我去看心理医生？您还真是有先见之明啊，这可都是您们的成就啊！然而，赵老师，（化学）王老师，我也要感谢您们，真心的感谢您们。感谢您们能够公平的对待我，能够就事论事的批评或表扬，能够在我成绩差的时候给我以批评和鼓励而不是轻蔑的眼光。如同黑暗中的烛火，没有您们，我将消沉，而今天取得的一切都将成为不可能。 我还要感谢大学里面某些唯成绩论的诸位主管学生工作的老师们。保研曾是我大学时的梦想。04年四月的某个上午，“你的平均分怎么样？”“大概前三分之一吧”“三分之一？你回去吧，我很忙”，短短的三句话，几年来的努力和梦想在一瞬间幻灭。我跑回寝室大哭了一场。最近十年来唯一的一场。在这之前，曾有过两个老师跟我说过希望我在他们那里读研。就在这件事发生一周后，SRTP项目答辩上还有一位控制系的老师对我的工作感兴趣并希望我去跟他谈谈。在浙大的时候，几乎每一位带过我的导师都跟我说过希望我能在他/她手下继续读研，但直到今天，在一个距离浙江大学数万公里之遥的地方，这样的话才真正得到了兑现。这一切仅仅是因为我惨不忍睹的政治类课程成绩和主观学生工作的老师们的“我很忙”。竟然仅仅是一句“我很忙”！然而，塞翁失马，焉知非福，只此一句足以。曾几何时，我是一个被浙江大学研究生院抛弃的本科毕业生，我不会——永远不会——忘记这一点。 我还要谢很多人，更多人，我的家人，朋友，绝大多数同学和恩师，以及很多很多其它的人。那些都是正常的致谢，当然。即使是最阴霾天气，天空也依然被阳光照亮。然而这样的致谢词我已经在不同的地方写过很多次，这里便不在赘述了。 从93年初次走进课堂，一路过来已是十五年，就此致谢，告一段落。今天，在前人所未及之地，我的探索之旅正式开始。 2008/10/2 祸兮？福兮？Hans Rausing奖学金的结果出来了，没拿到。早上收到一封信，写的叫个经典啊：“介于所有候选人都很牛，我们确实很难做一个决定。尽管如此，我现在已经可以公布，奖学金将颁发给生物工程系的候选人”，绝的在下面一句：“如果因为任何原因使得他们不能接受，计算机系的候选人将作为后备”。呵呵，感觉好像是抽奖抽到“恭喜您，就差一点点”一样，这要是写个“谢谢惠顾”不是大家心理上都能好过点么-__-b 只好给老板做Part Time RA赚学费了。不过说起来这个工资（25~28K/Annual）说不定还比奖学金多呢。虽然少了一个很好看的Resume Builder，研究方向又被项目框死了，但是横竖还是能接着拿funding读PhD，我也就不多抱怨什么了。 2008/10/1 英国的用词习惯和生活点滴(1)我也写点无聊的东西。这都是我日常生活中自己总结出来的，没啥参考资料，难免有错，大家随便看看就得了。 1.地铁：在伦敦这个地方过日子，没有地铁绝对寸步难行。地铁的说法英语课本上好像有，叫Subway。但是在英国，Subway一般指的是人行地下通道。伦敦地铁站的标志上写的都是Underground。还有一种更大众的说法是Tube。比如地铁图就叫Tube Map，地铁站叫Tube Station，等等。我记得在美国地铁也不叫Subway，至少在华盛顿和纽约地铁站标的都是Metro。所以我也挺奇怪为什么当初英语课本上教的是个大家都不用的词。 2.咖啡：熬夜赶项目，咖啡是必不可少的‘生产要素’之一。但是英国人喝咖啡就跟咱们喝茶一样，有很多讲究。就跟咱们把茶叶分成龙井、毛尖、香片等种类一样，他们也给不同类型的咖啡起了很多名字。首先说说冲调好的咖啡。在国内过的比较滋润，经常去Starbucks的同志们估计对这块是很熟悉了，不过为了完整我还是说一下吧。一般来说，常见的咖啡冲调方法有Espresso, Cappuchino, Latte, Mocha和American Coffee（不确定拼写，反正都是些外来词，音对就成了）这五种。去咖啡店买的时候您就不能只说要Coffee了，得说明到底要的是哪种。Espresso: 浓缩咖啡，就是加水很少所以巨浓的咖啡，不加糖和奶。因为Espresso浓，所以相应的用的杯子也很小，跟国内的喝白酒的小杯差不多大。Cappuchino：奶沫咖啡：下面是白咖啡（White Coffe12e，加奶的咖啡，记得这个英语课本里也有吧。对应的，不加奶的就是Black Coffee），上面一层奶沫。这种咖啡是最常见的，喝的时候得有点本事才能把奶沫一起喝下去，您就自己摸索吧。Latte：奶很多的白咖啡。Mocha：加了巧克力粉的白咖啡。American Coffee，最‘没品’的东西，其实就是清咖啡。这里还得说一句，一般那些咖啡在上的时候都没有糖，得自己加，但是Mocha例外。因为巧克力粉是甜的，所以Mocha本身就很甜，如果再加糖就难喝了。笔者自己就犯过这个错误。虽然咖啡店在英国不像在中国那么奢侈（相对来说），但是去咖啡店买还是挺贵的，而且也不是哪都有店。在学校要喝咖啡一般都是从自动售卖机（Vending Machine）那里买。其实自动售卖机出来的咖啡不见得差。比如有些机器是用磨碎的咖啡豆冲泡的，味道和店里卖的差不多。 不管是店里卖的还是自动售货机，都比自己冲泡要贵不少，所以买包咖啡放在家里或实验室是很有必要。这时候就得注意看袋子上写的东西了。首先是种类。整粒的咖啡豆一看样子就能看出来，但是Grounded Coffee和Instant Coffee看上去就差不多了，都是粉末，很容易搞混。Grounded Coffee是磨碎的咖啡豆，不能全部溶解，冲完之后必须用专门的滤纸把渣滓滤出来，还挺麻烦的。要省事的话就买Instant Coffee吧，直接冲完了就能喝。另外还要看咖啡的烘焙程度。一般分Brown，Medium Roasted和Dark Roasted三种。其中Dark Roasted是烘的最‘干’的，颜色也最深。如果买的不是用很好的原料做的咖啡（那样的咱也买不起），最好买Dark Roasted，否则会有较重的酸味。另外，买的时候还得特别注意看一下是不是脱咖啡因的（Decaf）。最后一点，有时候咖啡的包装上可能会印着Fair Trade，这跟咖啡本身没关系。Fair Trade是英国民间组织搞的一个项目，旨在保证不以掠夺式的低价购进原材料，并同时利用部分利润对原产地提供一些包括卫生、教育和基础设施建设等方面在内的援助。不过一般来说Fair Trade的东西都是比较差的（否则也就不存在‘掠夺式的低价’这种问题了），同时也都比较便宜。 |
|
|
%3a+2008%e5%b9%b410%e6%9c%88&referrer=){kind=small}
