Last year it was TimesTen and SleepyCat (BerkeleyDB).
This year it is Tangosol.
Who will be the next?
This database giant acquired Tangosol (vendor of Coherence data cache which has been used in many large financials), adding to its "Extreme Transaction Processing" initiative.
http://go.techtarget.com/r/1194471/5981609
http://www.oracle.com/tangosol/index.html
Wednesday, March 28, 2007
Installing Solaris 10 on SunFire V210
Because most of my time, I have spent in the development, this event is considered a rare occasion: a hands-on experience on plain Sun SPARC based 64-bit machine. This time I have it all in my power: SunFire V210. A machine which you could install, reinstall, configure, reconfigure the way you want it.
In my opinion, it was much easier to install Solaris 10 on Sun's machine, than it was to install one on a virtual machine, or even on an ordinary PCs. The Auto Layout Disk went smoothly, no failure is necessary.
This is actually a rather old machine, used to test the installation script. The client doesn't want to go to their client and install the application only to find out that there's something missing in the installation script. So we fetch out a machine similar to the production platform: a SunFire V245. It is of a bigger size (2U, I think) compared to V210 (1U).
In my opinion, it was much easier to install Solaris 10 on Sun's machine, than it was to install one on a virtual machine, or even on an ordinary PCs. The Auto Layout Disk went smoothly, no failure is necessary.
This is actually a rather old machine, used to test the installation script. The client doesn't want to go to their client and install the application only to find out that there's something missing in the installation script. So we fetch out a machine similar to the production platform: a SunFire V245. It is of a bigger size (2U, I think) compared to V210 (1U).
Powered by ScribeFire.
IEEE ComSoc Indonesia Chapter New Milis
Today I was invited to join the IEEE ComSoc (Communications Society) Indonesia mailing list. Only 10 members in the milis right now. It seems this mailing list is a new one, because everybody seemed to have joined either at March 27 or 28, 2007.
Looking forward for the fast advance in the communication society in Indonesia :D
Looking forward for the fast advance in the communication society in Indonesia :D
Powered by ScribeFire.
Tuesday, March 27, 2007
Ill Behaviored HTTP/1.1 Client
Today I've been message by my campus friend, asking an advice for tuning a SJAS. How many threads should he have for servlets, how many MDBs, and how many database connection in the pool.
He set the number for 1024, 128. Hmm. Very big. I asked him, how much memory and processor resources and app server instances do you have. The answer was shocking:
1 processor, 1 gigabyte, 1 instance
As far as I can remember, on a WebLogic they recommend to use less than that number of threads for best practices on each instances. Wow, and we were talking about WebLogic 8.1 instance in a UltraSPARC-IIIi Solaris 9 boxes with 8 gigs of memory!
I thought there must be something else happening. For just 1 processor, processing many threads is actually a waste of time in the context switching. I think it should not be like that. There something wrong when the system. It is already out of resource and the queue piles up. It must be some kind of resource starvation. Some resource may not be released during the process. Some resources are held for longer than it should be.
Then I remembered that I have had encountered some problems here.
The HTTP/1.1 Protocol has been there for such a long time. But there are some behavior most programmers still don't know.
The HTTP/1.1 differs from HTTP/1.0 that it implements persistent connection by default. The HTTP/1.1 will not be closing its connection after your client application exits. Your browser or client application by default will maintain HTTP connection until time out period elapsed. Before time out period, the connection is still up, and whenever you need to make more requests your browser or your HTTP client application will reuse the HTTP connection when possible, thus eliminating the overhead needed to setup such connections. The browser application makers have been doing their job very well it is transparent for us to such happenings in the protocol.
Remember I said 'by default', because you can explicitly asks the server (by adding a header field) to close the connection once the request has been fulfilled.
This is the thing that you need in your HTTP header.
Connection-Close: close
He set the number for 1024, 128. Hmm. Very big. I asked him, how much memory and processor resources and app server instances do you have. The answer was shocking:
1 processor, 1 gigabyte, 1 instance
As far as I can remember, on a WebLogic they recommend to use less than that number of threads for best practices on each instances. Wow, and we were talking about WebLogic 8.1 instance in a UltraSPARC-IIIi Solaris 9 boxes with 8 gigs of memory!
I thought there must be something else happening. For just 1 processor, processing many threads is actually a waste of time in the context switching. I think it should not be like that. There something wrong when the system. It is already out of resource and the queue piles up. It must be some kind of resource starvation. Some resource may not be released during the process. Some resources are held for longer than it should be.
Then I remembered that I have had encountered some problems here.
The HTTP/1.1 Protocol has been there for such a long time. But there are some behavior most programmers still don't know.
The HTTP/1.1 differs from HTTP/1.0 that it implements persistent connection by default. The HTTP/1.1 will not be closing its connection after your client application exits. Your browser or client application by default will maintain HTTP connection until time out period elapsed. Before time out period, the connection is still up, and whenever you need to make more requests your browser or your HTTP client application will reuse the HTTP connection when possible, thus eliminating the overhead needed to setup such connections. The browser application makers have been doing their job very well it is transparent for us to such happenings in the protocol.
Remember I said 'by default', because you can explicitly asks the server (by adding a header field) to close the connection once the request has been fulfilled.
This is the thing that you need in your HTTP header.
Connection-Close: close
My New ScribeFire!
When I tried to download latest version of Thunderbird mail client, I find this cool tools. I can post my blog through this tool in my Firefox browser.
This is the result of it...
Wow, now it is easier to post something in the blog. This tool will do the rest for me.
This is the result of it...
Wow, now it is easier to post something in the blog. This tool will do the rest for me.
Powered by ScribeFire.
Subscribe to:
Posts (Atom)