第二天七时正久等其他乘客,八点半方抵达“克隆三”(Khlong San)码头,大概迟了一个小时吧。在码头上了船后,我们就在湄南河(Chau Phraya River 泰王河) 乘风破浪观看河边景色及建筑物等,之间有船小贩把舢舨停在我们的船旁兜售各种旅游纪念品。我们的船在郑王庙停了一会儿就回航了。
接下来我们一团去祭拜四面神。四面神位于闹市中心,附近好刚建好了一个快铁站,以后信徒游客要来这儿也方便多了。四面神旧称四面佛,是兴都教的创造之神Brahma,所以名字从四面佛改为四面神较为贴切。四面神位处露天,没立庙,香火鼎盛,信徒源源不绝举香朝四面神的四个面孔下跪、祈求、许愿,在烈日下诚心祭拜。
过后我们前往野生世界,看大马也有的东西,不外是飞禽走兽加表演,吾对这样的安排真是哭笑不得。事情看两面,其实也非没有所获,吾发现中国崛起对泰国旅游业的影响真的很大,在海豚表演环节上,当局竟先以华语解说英语其次,华语俨如国际语言。开心的事,接下来数天有好些节目语言也以华语为主,可见大陆人蜂拥在世界各地旅行大幅度的影响当地。
炎热的午后让吾吃不消,所幸之后是长途之旅,我们一团前往芭提雅(Pattaya)以消耗整个晚上。途中免不了又安排一个什么文化表演(Alangkarn), 四处打量好像只有我们一团,开什么玩笑?不过,那表演也不错啦,值得一看。还有,这个节目的首选解说语言是华语哦。
看到了一路上的丰田车,我想到了马来西亚的骄傲-普腾,我没有荣幸,反之我很肚烂。来玩都会不开心,吾要普腾赔偿精神上的损失。
抵达芭提雅日已落。晚间节目色情味十足,有性交秀(俗称69)等等等,我需与家人选择看人妖秀,那些人妖们专业的演出不仅值得门票,也值得掌声鼓励。某些团友不满意这些安排,说在吉隆坡都不知已看了好几回了,呵呵,起火了,火苗尚小。
由于导游把许多其他天的行程挤进第二日,我们就在水上市场要关的半个小时前匆匆赶到参观,这个水上市场很商业化,跟我在龙虎门看到的不一样,就是石黑龙假扮游客试探元始门的那个,不知是一样的吗?可能此水上市场非彼水上市场吧。
晚餐也是一样烂。
Friday, February 26, 2010
曼谷芭提雅游 (一)
趁穆斯林开斋佳节母亲没做工,吾与家人出游曼谷与芭提雅。
我们的亚航飞机于黄昏时刻起飞,并在当地时间五点多抵达,到站后再去与之前已联络好的导游见面。导游是一位年龄四五十岁左右的“安哥”,自称“麦哥”,华裔泰国人,说得一口流利星马式中文,说话幽默风趣,善于化解游客投诉(之后再提)。麦哥大部分时间都很尽责,但有时对游客的问题与投诉置若罔闻。我们的旅途中有数名团友发飙,请容本人之后再提。
我们上了一辆7人休旅车,就往酒店出发,酒店乃位于“马卡桑”(Makassan)的“曼谷皇宫”(Bangkok palace)。完成登入酒店房手续,并安置了行李后,麦哥带我们三人吃晚餐,地点就在我们下榻酒店的不远处。途中我们陆陆续续与同一团的游客集合,他们都入住不同酒店,以北马人居多。
好了,晚餐地点到了,哇食物好真叫人失望,今晚我们竟然是吃中餐。但是,吾肚子饿了所以也不计较,横扫桌上菜肴。
晚餐后是当地时间八点多,导游也没为我们安排节目,我们就被送回酒店了。本来还想搭德士前往当地出名的市集,但根据晚餐前从那儿回来的团友所述,市集处交通混乱,加上下了雨积水更变本加厉。母亲听了便打消了这个念头,本人着实扫兴。
之后我提议到酒店附近走走,家人也没问题,我们就去乱走一通了。我们在一个路边摊买了马来西亚也有的蚝煎,偷偷的带回酒店房内吃,哇,味道还真不错!很香脆。我们三人大快朵颐很快就解决了那包蚝煎,我是觉得意犹未尽啦,呵呵。
就这么过了数小时的第一天。
我们的亚航飞机于黄昏时刻起飞,并在当地时间五点多抵达,到站后再去与之前已联络好的导游见面。导游是一位年龄四五十岁左右的“安哥”,自称“麦哥”,华裔泰国人,说得一口流利星马式中文,说话幽默风趣,善于化解游客投诉(之后再提)。麦哥大部分时间都很尽责,但有时对游客的问题与投诉置若罔闻。我们的旅途中有数名团友发飙,请容本人之后再提。
我们上了一辆7人休旅车,就往酒店出发,酒店乃位于“马卡桑”(Makassan)的“曼谷皇宫”(Bangkok palace)。完成登入酒店房手续,并安置了行李后,麦哥带我们三人吃晚餐,地点就在我们下榻酒店的不远处。途中我们陆陆续续与同一团的游客集合,他们都入住不同酒店,以北马人居多。
好了,晚餐地点到了,哇食物好真叫人失望,今晚我们竟然是吃中餐。但是,吾肚子饿了所以也不计较,横扫桌上菜肴。
晚餐后是当地时间八点多,导游也没为我们安排节目,我们就被送回酒店了。本来还想搭德士前往当地出名的市集,但根据晚餐前从那儿回来的团友所述,市集处交通混乱,加上下了雨积水更变本加厉。母亲听了便打消了这个念头,本人着实扫兴。
之后我提议到酒店附近走走,家人也没问题,我们就去乱走一通了。我们在一个路边摊买了马来西亚也有的蚝煎,偷偷的带回酒店房内吃,哇,味道还真不错!很香脆。我们三人大快朵颐很快就解决了那包蚝煎,我是觉得意犹未尽啦,呵呵。
就这么过了数小时的第一天。
Thursday, February 11, 2010
Issue with Java Security Provider
While working on one enhancement. I encountered a weird problem. The program within WBIA framework failed in calling web service. It was throwing me a NullPointerException from Axis library as below:
at java.security.SecureRandom.nextBytes(SecureRandom.java:433)
at org.apache.axis.utils.SessionUtils.generateSessionId(SessionUtils.java:62)
at org.apache.axis.SOAPPart.<init>(SOAPPart.java:164)
at org.apache.axis.Message.setup(Message.java:377)
at org.apache.axis.Message.<init>(Message.java:246)
at org.apache.axis.client.Call.invoke(Call.java:2425)
at org.apache.axis.client.Call.invoke(Call.java:2366)
at org.apache.axis.client.Call.invoke(Call.java:1812)
I made the investigation as below:
1) I put a java.security.Security.getProviders() in my program to list all the security providers. I compared the results from successful call (standalone java program running at the same AIX server) and unsuccessful call (program extending from WBIA framework running at the same AIX server).
Here is the result:
//Unsuccessful call.
- IBMJSSE2
- IBMJGSSProvider
- IBMCertPath
//Successful call
- IBMJSSE2
- IBMJCE
- IBMJGSSProvider
- IBMCertPath
- IBMSASL
Obviously some security providers are missing hence caused the unsuccessful call. I double confirmed this by modifying my java.security file at local and tested the same program from my local. Yes the web service call actually failed due to the missing security provider. The missing security provider is actually com.ibm.crypto.provider.IBMJCE
Therefore, i did the below the solve this issue:
1) Set the Java home path to the JRE folder instead of the JDK folder itself.
2) I added the security provider at runtime.
java.security.Security.addProvider(new com.ibm.crypto.provider.IBMJCE());
Finally it worked. One question is, how come it somehow did not refer to the java.security file that i set everything correctly else i do not have to do the 2nd step as mentioned. I still need to find out this.
at java.security.SecureRandom.nextBytes(SecureRandom.java:433)
at org.apache.axis.utils.SessionUtils.generateSessionId(SessionUtils.java:62)
at org.apache.axis.SOAPPart.<init>(SOAPPart.java:164)
at org.apache.axis.Message.setup(Message.java:377)
at org.apache.axis.Message.<init>(Message.java:246)
at org.apache.axis.client.Call.invoke(Call.java:2425)
at org.apache.axis.client.Call.invoke(Call.java:2366)
at org.apache.axis.client.Call.invoke(Call.java:1812)
I made the investigation as below:
1) I put a java.security.Security.getProviders() in my program to list all the security providers. I compared the results from successful call (standalone java program running at the same AIX server) and unsuccessful call (program extending from WBIA framework running at the same AIX server).
Here is the result:
//Unsuccessful call.
- IBMJSSE2
- IBMJGSSProvider
- IBMCertPath
//Successful call
- IBMJSSE2
- IBMJCE
- IBMJGSSProvider
- IBMCertPath
- IBMSASL
Obviously some security providers are missing hence caused the unsuccessful call. I double confirmed this by modifying my java.security file at local and tested the same program from my local. Yes the web service call actually failed due to the missing security provider. The missing security provider is actually com.ibm.crypto.provider.IBMJCE
Therefore, i did the below the solve this issue:
1) Set the Java home path to the JRE folder instead of the JDK folder itself.
2) I added the security provider at runtime.
java.security.Security.addProvider(new com.ibm.crypto.provider.IBMJCE());
Finally it worked. One question is, how come it somehow did not refer to the java.security file that i set everything correctly else i do not have to do the 2nd step as mentioned. I still need to find out this.
Monday, November 30, 2009
再临华美 Hua Mui Revisited
既然到了新山,我当然会去华美,吃吃它的面包,喝喝它的咖啡,体验殖民地风情,享受慵懒的午后气氛。
Been to Hua Mui once more! Yummy Yummy Hua Mui

外观
Hua Mui here i come again!

内观

内观

非常殖民地风味
Love the colonization era feel. It reminds me this restaurant is close to 100 years old.

叫了杯茶c
I ordered Teh-C. Good. Very Kow.

叫了面包,好吃好吃。
The toast banyak bagus! Delicious. Enak betul.
Been to Hua Mui once more! Yummy Yummy Hua Mui

外观
Hua Mui here i come again!

内观

内观

非常殖民地风味
Love the colonization era feel. It reminds me this restaurant is close to 100 years old.

叫了杯茶c
I ordered Teh-C. Good. Very Kow.

叫了面包,好吃好吃。
The toast banyak bagus! Delicious. Enak betul.
永平福州鱼丸 Yong Peng FuZhou Fish Ball

哇,首尝福州鱼丸。
Yummy. First time eating FuZhou fish ball.
以往多次路经永平,对荣凯的西刀鱼丸鱼饼情有独钟,所以无缘尝试其他店的鱼丸。
I love XiDao Fish Ball. I used to eat a lot of XiDao Fish Ball & Fish Cake at a shop called Antony's every time i traveled back to my home town.
这次由于已近晚上十点,荣凯已闭门休息。唯有试试别家鱼丸,找上了这间。
Last Friday night at 10pm, i wanted to have dinner at Antony's, which had already closed. Therefore i had my dinner at this shop (i have forgotten the shop name).
其干面与鱼丸配搭没荣凯出色,其鱼饼似乎与荣凯的同出一源。让我欢喜的是那一晚福州鱼丸。鱼丸里头裹着猪肉,是新发明吧?非同凡响,值得一试!
There is a piece of meat inside the fish ball. New invention? Worth trying!
Wednesday, November 11, 2009
Load Test
Past few days i encountered one serious production issue, which the web service timeout before the backend process sent back the message to the SOAP response node in WMB flow. This was due to the high load in production that caused the delay in the backend process.
The whole process is: WMB flow extracts SOAP request message, turns it into a MQ Header message, puts the message to Java adaptor's request queue, then Java adaptor processes the content and puts a response message to the response queue, then WMB flow will read the message in the response queue and will turn it into a SOAP response.
In the progress of investigation, we decided to move one database query out from the java adaptor program to the WMB flow. The reason being is sometimes the db connection will just drop and the java adaptor program has to spend some time reinitiating the db connection. In fact according to the time recorded in the adaptor's log the process was still quite fast, it's even within miliseconds. Well we just gave it a try.
After making all the necessary changes we deployed the works to the testing environment. I then performed some load tests to the web service. The result was negative. The tps was around 3.5 but the average time taken was > 10 seconds and we had to achieve < 10 seconds! So still plenty of work to do :(
We performed a few cycles of investigation, trial and error & testing until we found the solution - increasing the WMB flow instance. This is a setting in the WMB Toolkit. So we increased the number of instances to 3. This time we managed to achieve an average time of 3 seconds! We were so happy and excited!
What about the cause? See below:
There were many messages piling at the response queue which is supposed to be read by the WMB flow. These messages were sent in by the Java Adaptor after it finished processing the data. Apparently these messages were not picked up by the WMB flow in time hence causing the timeout error. By increasing the WMB flow instance, concurrently there are 3 identical WMB flows reading the content of this queue, hence problem resolved!
I was really relieved!
The whole process is: WMB flow extracts SOAP request message, turns it into a MQ Header message, puts the message to Java adaptor's request queue, then Java adaptor processes the content and puts a response message to the response queue, then WMB flow will read the message in the response queue and will turn it into a SOAP response.
In the progress of investigation, we decided to move one database query out from the java adaptor program to the WMB flow. The reason being is sometimes the db connection will just drop and the java adaptor program has to spend some time reinitiating the db connection. In fact according to the time recorded in the adaptor's log the process was still quite fast, it's even within miliseconds. Well we just gave it a try.
After making all the necessary changes we deployed the works to the testing environment. I then performed some load tests to the web service. The result was negative. The tps was around 3.5 but the average time taken was > 10 seconds and we had to achieve < 10 seconds! So still plenty of work to do :(
We performed a few cycles of investigation, trial and error & testing until we found the solution - increasing the WMB flow instance. This is a setting in the WMB Toolkit. So we increased the number of instances to 3. This time we managed to achieve an average time of 3 seconds! We were so happy and excited!
What about the cause? See below:
There were many messages piling at the response queue which is supposed to be read by the WMB flow. These messages were sent in by the Java Adaptor after it finished processing the data. Apparently these messages were not picked up by the WMB flow in time hence causing the timeout error. By increasing the WMB flow instance, concurrently there are 3 identical WMB flows reading the content of this queue, hence problem resolved!
I was really relieved!
Subscribe to:
Posts (Atom)
