没有希望就没有失望,没有失望就不会像现在这样。
我不想假装我没有期待过。
我不想假装我没有对这次的事情很失望。
可是当我老板问起满不满意时,我还是笑笑说满意。
是因为我自己觉得我不够资格得到更多吗?不是啊。应该是我怕别人说我不自量力吧。
螳臂当车,不自量力。
我其实也没有想怎样啊。。我只想拿回我应该得到的。。
唉。。
Tuesday, January 25, 2011
Friday, January 21, 2011
<转载> 新的旧的都一样
一个朋友的婚礼上
司仪拿出一张百元钞票问在场所有人
谁想要请举手
大家想怕是司仪想出来整人的花招吧?
没人说话
司仪说:
我说真的
想要的请举手
终于有人举手了
接着越来越多的人举手了
司仪拿出一张百元钞票问在场所有人
谁想要请举手
大家想怕是司仪想出来整人的花招吧?
没人说话
司仪说:
我说真的
想要的请举手
终于有人举手了
接着越来越多的人举手了
司仪看了看大家
换了一张旧的百元钞票
举手的人明显的少了许多
司仪笑了笑了
又换了张皱巴巴的有点破损的旧百元钞票
但是现场举手的人寥寥无几了
司仪请了一位小男孩上台
并把那张旧钞票放在他的手里说:
因为他一直举着手
下面的人哄堂大笑
小男孩的脸有些发红
司仪摆摆手示意大家安静
拿出那张新的百元钞票说:
我这张新的跟你那张旧的换换
可以吗?
小男孩说:
不用了
谢谢叔叔
新的旧的都一样
司仪点点头
让小男孩拿着钱下去了
司仪让新郎新娘手拉手走上台说:
再美丽的容颜总有老去的一天
再浪漫的爱情也会随着生活的变化而变化
就如同我手中的钞票一样
随着时间的变化会慢慢变皱、变旧
但是也像那小男孩说的"新的旧的都是一百元"
它的价值不会因为上面的皱褶而改变
不是吗?
希望新人能懂得爱情真正的价值和意义
不要等到容颜老去
或是激情化为平淡的时候
就忘记了刚才亲口说出的<爱你一生一世>的誓言
请你们珍惜对方一辈子
新人对望了一下深深的点点头
台下暴发了热烈的掌声
大多数的人终其一生
不停地渴望、不停地追求、不停地夺取
却不知道珍惜手边的幸福
到头来一无所有
什么也没得到
换了一张旧的百元钞票
举手的人明显的少了许多
司仪笑了笑了
又换了张皱巴巴的有点破损的旧百元钞票
但是现场举手的人寥寥无几了
司仪请了一位小男孩上台
并把那张旧钞票放在他的手里说:
因为他一直举着手
下面的人哄堂大笑
小男孩的脸有些发红
司仪摆摆手示意大家安静
拿出那张新的百元钞票说:
我这张新的跟你那张旧的换换
可以吗?
小男孩说:
不用了
谢谢叔叔
新的旧的都一样
司仪点点头
让小男孩拿着钱下去了
司仪让新郎新娘手拉手走上台说:
再美丽的容颜总有老去的一天
再浪漫的爱情也会随着生活的变化而变化
就如同我手中的钞票一样
随着时间的变化会慢慢变皱、变旧
但是也像那小男孩说的"新的旧的都是一百元"
它的价值不会因为上面的皱褶而改变
不是吗?
希望新人能懂得爱情真正的价值和意义
不要等到容颜老去
或是激情化为平淡的时候
就忘记了刚才亲口说出的<爱你一生一世>的誓言
请你们珍惜对方一辈子
新人对望了一下深深的点点头
台下暴发了热烈的掌声
大多数的人终其一生
不停地渴望、不停地追求、不停地夺取
却不知道珍惜手边的幸福
到头来一无所有
什么也没得到
Labels:
小故事,大道理
Sunday, January 16, 2011
Saturday, January 15, 2011
Wednesday, January 12, 2011
Sunday, January 09, 2011
20100108 - Bukit Tabur
第一次的爬山,还蛮恐怖的。脚力真的不够。我们从7点多开始,直到12点半才结束。本来还没什么信心可以完成整个路程的。不过,最后还是做到了。还真的有点小骄傲。至少又有个突破了吧。我老板还说我有爬山的潜质哦。哈哈。
不知名的湖。。不同的高度下看到不同的风景

不知名的湖。。不同的高度下看到不同的风景
Labels:
小眼睛,看世界
Friday, January 07, 2011
<转载>帮你是出于交情,不帮你是应该
A不喜欢吃鸡蛋,每次发了鸡蛋都给B吃。刚开始B很感谢,久而久之便习惯了。习惯了,便理所当然了。于是,直到有一天,A将鸡蛋给了C,B就不爽了。她忘记了这个鸡蛋本来就是A的,A想给谁都可以。为此,她们大吵一架,从此绝交。
有一年,很热的夏天,一队人出去漂流。
女孩的拖鞋在玩水的时候,把拖鞋掉下去了,沉底了。到岸边的时候,全是晒的很烫的鹅卵石,他们要走很长的一段路。于是,女孩儿就向别人寻求帮忙,可是谁都只有一双拖鞋。女孩心里很不爽,因为她习惯了向别人求助,而只要撒娇就会得到满意地答复。可是这次却没有。她忽然觉得这些人都不好,都见死不救。
后来,有一个男孩将自己的拖鞋给了她,然后自己赤脚在那晒得滚烫的鹅卵石上走了很久的路。还自嘲说是铁板烧。女孩表示感谢,男孩说,你要记住,没有谁是必须要帮你的。帮你是出于交情,不帮你是应该。女孩记住了男孩的话,自此以后学会了对施以援手的人铭记在心,并给以更大的回报。
很多时候,我们总是希望得到别人的好。
一开始,感激不尽。可是久了,便是习惯了。习惯了一个人对你的好,便认为是理所应当的。有一天不对你好了,你便觉得怨怼。其实,不是别人不好了,而是我们的要求变多了。习惯了得到,便忘记了感恩。
有一年,很热的夏天,一队人出去漂流。
女孩的拖鞋在玩水的时候,把拖鞋掉下去了,沉底了。到岸边的时候,全是晒的很烫的鹅卵石,他们要走很长的一段路。于是,女孩儿就向别人寻求帮忙,可是谁都只有一双拖鞋。女孩心里很不爽,因为她习惯了向别人求助,而只要撒娇就会得到满意地答复。可是这次却没有。她忽然觉得这些人都不好,都见死不救。
后来,有一个男孩将自己的拖鞋给了她,然后自己赤脚在那晒得滚烫的鹅卵石上走了很久的路。还自嘲说是铁板烧。女孩表示感谢,男孩说,你要记住,没有谁是必须要帮你的。帮你是出于交情,不帮你是应该。女孩记住了男孩的话,自此以后学会了对施以援手的人铭记在心,并给以更大的回报。
很多时候,我们总是希望得到别人的好。
一开始,感激不尽。可是久了,便是习惯了。习惯了一个人对你的好,便认为是理所应当的。有一天不对你好了,你便觉得怨怼。其实,不是别人不好了,而是我们的要求变多了。习惯了得到,便忘记了感恩。
Labels:
小故事,大道理
Thursday, January 06, 2011
<转载>Stuck Thread
A stuck thread means a thread is blocked and can't return to the thread pool smoothly in a given period of time. When an application thread is blocked unintentionally, it means it can't quickly complete its dispatch and be reused. In most of production situations, the root cause of these stuck threads is also the root cause of bad system performance because it interferes with regular task execution. [It's also a performance issue for producers and healthy consumers. < 1 ] (request frequency) < (healthy thread count for request execution/average measured request execution time per healthy thread.]
Blocking without specifying a network connect or read timeout is the most frequent reason we have seen. When we don't manually configure a timeout for each method call involving networking, it will have a potential blocking behavior by the underlying physical socket read/connect characteristic. While waiting infinitely for the response from the other side, the native OS networking layer probably throws an I/O exception. By default this behavior takes an unexpectedly long time (e.g., 240 seconds). Modern distributed systems need to factor in this situation (especially, Web Services invocations). Though we may set timeouts for well-known protocols via some system properties (e.g., sun.net.client.defaultConnectTimeout and sun.net.client.defaultReadTimeout), the newer version of JDK might provide a generic mechanism to explicitly configure each default timeout value for those whose methods call socket connect/read as a security policy file. For example, com.sun.jndi.ldap.read.timeout (http://java.sun.com/docs/books/tutorial/jndi/newstuff/readtimeout.html) wasn't available prior to JDK 6.0 for LDAP service provider read timeout. Otherwise, when the problematic code isn't under the control of end users, it usually needs to restart the application to temporarily reset the abnormal phenomenon propagated from the other side. In addition, we should take into account whether the service we called is idempotent while analyzing this kind of issue in the design phase because we don't know whether the service at the other end keeps executing when the thread has ended its invocation after a timeout (see Figure 4).
The unexpectedly long execution time of a SQL statement is a common condition that causes a stuck thread. In the thread dump we collected, we can see that the stuck thread was running a network socket read for a long time without changes and the thread's stack trace contains many JDBC driver classes. Under these conditions, we can also check the status of the database it connected with and set the query timeout for all application code using a JDBC statement setQueryTimeout method. (Most JDBC drivers support this feature but we'd have to read the JDBC driver's release note first.) According to the different nature of every SQL query, it would be better to segregate the programs that have a longer execution time in another thread pool and tune the database table with indices for faster access. We would also need to check whether the JDBC driver is certified with the connected database. A sub-issue is the accessed table locked by other processes so the threads for the JDBC query couldn't continue because of table locking.
Resource contention is an issue that's hard to find if we don't get the entire thread dump to analyze. Basically, it's an issue of producers and consumers. Any limited resources on the system (JDBC connections, socket connections, etc.) will impact this issue. The best thing to do is look at the thread dump, get the stuck thread name from the log, and find the bottleneck that's causing the stuck thread.
File descriptor leaking is an issue that causes this phenomenon (Note that a Unix socket implementation requires a file descriptor). So the JVM should have enough file descriptor numbers to host our applications. Generally, we can adjust the open file limit with the Unix shell 'ulimit' command for the current shell. And we can list the open files with the public domain 'lsof' tool. It's intensely interesting that many developers don't explicitly use the 'close()' method in the final block when an object inherently provides a 'close()' method and want JVM to release these unclosed objects when garbage is collected. We should keep firmly in mind that that act is bad without closing the system resource after use. A special case is when the socket connections in the application don't close properly while still being underdeployed and then the application begins to throw an IOException with a 'Too many open files' message after repeated application redeployment.
Quotes from :
http://java.sys-con.com/node/358060 Looking Inside Stuck Thread
Blocking without specifying a network connect or read timeout is the most frequent reason we have seen. When we don't manually configure a timeout for each method call involving networking, it will have a potential blocking behavior by the underlying physical socket read/connect characteristic. While waiting infinitely for the response from the other side, the native OS networking layer probably throws an I/O exception. By default this behavior takes an unexpectedly long time (e.g., 240 seconds). Modern distributed systems need to factor in this situation (especially, Web Services invocations). Though we may set timeouts for well-known protocols via some system properties (e.g., sun.net.client.defaultConnectTimeout and sun.net.client.defaultReadTimeout), the newer version of JDK might provide a generic mechanism to explicitly configure each default timeout value for those whose methods call socket connect/read as a security policy file. For example, com.sun.jndi.ldap.read.timeout (http://java.sun.com/docs/books/tutorial/jndi/newstuff/readtimeout.html) wasn't available prior to JDK 6.0 for LDAP service provider read timeout. Otherwise, when the problematic code isn't under the control of end users, it usually needs to restart the application to temporarily reset the abnormal phenomenon propagated from the other side. In addition, we should take into account whether the service we called is idempotent while analyzing this kind of issue in the design phase because we don't know whether the service at the other end keeps executing when the thread has ended its invocation after a timeout (see Figure 4).
The unexpectedly long execution time of a SQL statement is a common condition that causes a stuck thread. In the thread dump we collected, we can see that the stuck thread was running a network socket read for a long time without changes and the thread's stack trace contains many JDBC driver classes. Under these conditions, we can also check the status of the database it connected with and set the query timeout for all application code using a JDBC statement setQueryTimeout method. (Most JDBC drivers support this feature but we'd have to read the JDBC driver's release note first.) According to the different nature of every SQL query, it would be better to segregate the programs that have a longer execution time in another thread pool and tune the database table with indices for faster access. We would also need to check whether the JDBC driver is certified with the connected database. A sub-issue is the accessed table locked by other processes so the threads for the JDBC query couldn't continue because of table locking.
Resource contention is an issue that's hard to find if we don't get the entire thread dump to analyze. Basically, it's an issue of producers and consumers. Any limited resources on the system (JDBC connections, socket connections, etc.) will impact this issue. The best thing to do is look at the thread dump, get the stuck thread name from the log, and find the bottleneck that's causing the stuck thread.
File descriptor leaking is an issue that causes this phenomenon (Note that a Unix socket implementation requires a file descriptor). So the JVM should have enough file descriptor numbers to host our applications. Generally, we can adjust the open file limit with the Unix shell 'ulimit' command for the current shell. And we can list the open files with the public domain 'lsof' tool. It's intensely interesting that many developers don't explicitly use the 'close()' method in the final block when an object inherently provides a 'close()' method and want JVM to release these unclosed objects when garbage is collected. We should keep firmly in mind that that act is bad without closing the system resource after use. A special case is when the socket connections in the application don't close properly while still being underdeployed and then the application begins to throw an IOException with a 'Too many open files' message after repeated application redeployment.
Quotes from :
http://java.sys-con.com/node/358060 Looking Inside Stuck Thread
Labels:
爪哇方程式遇上甲骨文
Tuesday, January 04, 2011
Sunday, January 02, 2011
The Curve - Bubba Gump
That was a few nights after Xmas. Darling said wish to bring me to a better place rather than having dinner around office. "A secret place for us to dinner" - darling said so. Although he had no idea where to eat. We stopped at this restaurant "Bubba Gump". This also the place that we celebrated his birthday for his 25th yrs old.
A good place for prawn lovers. =) Whole menu full with prawn and shrimp. But still provides some others food like fish and chips, chicken chop and bla bla bla. As for a person who doesn't love seafood, i chose fish and chips. =D
The logo for this restaurant, a smiling shrimp. But it doesnt look that cute. haha.

A signboard on the table. "Run Forrest Run", it tells the waiters u do not need their serving at that moment.

"Stop Forrest Stop" - It's time for serve us now. They are very sensitive to this sign. Do not simply flip to this sign unless you reali wish to. haha.

A good place for prawn lovers. =) Whole menu full with prawn and shrimp. But still provides some others food like fish and chips, chicken chop and bla bla bla. As for a person who doesn't love seafood, i chose fish and chips. =D
The logo for this restaurant, a smiling shrimp. But it doesnt look that cute. haha.

A signboard on the table. "Run Forrest Run", it tells the waiters u do not need their serving at that moment.

"Stop Forrest Stop" - It's time for serve us now. They are very sensitive to this sign. Do not simply flip to this sign unless you reali wish to. haha.

Labels:
Jalan-Jalan Cari Makan
Subscribe to:
Posts (Atom)


