Sunday, September 20, 2009

IBM WebSphere Commerce Websites Gallery

Here are some of the shopping websites created using IBM WebSphere Commerce Suite. You can find all sorts of top brand companies ranging from Electronics retailers, Garments retailers, government, etc.Also you can search "/wcs/stores" keyword search in google to list all the websites developed using IBM Commerce Suite, provided they haven't changed the default context root.

Saturday, September 19, 2009

Tips to get most out of IBM Support

I am sure many of you might already worked with IBM support to resolve problems related to the product , but here are some tips that you can follow to effectively reduce the problem resolution time and ease the process.

1) If you suspect if the problem is product related, start by opening a service request or PMR (Problem Management Record) either through online or by calling the IBM Support 1-800-IBM-SERV. You might need a IBM customer number.

2) Start with a simple description of the problem when you open a PMR.

3) Make sure you provide a clear description in such a way it represents the problem area so that your PMR gets assigned to the right team as there are several teams with different specialization within the same product , so that you will save time by getting the problem assigned to the correct team. If you know the team before hand then specify the team queue in the PMR.

4) Specify mode of communication in the PMR either by email or phone. If you think the problem is complex and need some explanation to do, then specify phone call back so that IBM support representative can call back and understand the problem, if you think the problem something trivial a little description in the PMR would make them understand then specify email.

5) Collect MustGather documents either manually or using http://www-01.ibm.com/software/support/isa/ IBM Support Assistant tool and then attach the the logs to PMR which will help in faster resolution to the PMR.

6) If possible, try to create a reproducible test case preferably outside to your custom application, so that IBM can use this test case to test it in the lab and provide a solution, Also it will also help to isolate that the problem is not related to your company's custom code or the environment.

7) Please use commonly used terminologies when updating the PMR or talking to IBM Support representative instead of the terminologies that you might use within your IT department as it might confuse the person handling the PMR as different companies use different ways to describe a problem. Clarify things if and when needed.

8) Specify the severity and priority in the PMR, Be reasonable and provide a business justification, set your expectations like when you need the next update and when the problem should be resolved, so that they can work towards it.

9) Please update the PMR with any new findings and updates as and when you come to know or also when you need progress updates from IBM.

10) Understand the escalation procedure and use it to escalate when things are not moving as reasonably expected.

11) Be friendly and appreciate the IBM Support representative work when problem gets resolved.

12) Follow the instructions from IBM even though it doesn't make sense sometimes , otherwise it would become a bottleneck to proceed to the next step in debugging the problem.

13) Besides doing all the above you can also self serve simultaneously by searching support knowledge base, infocenter , forums , etc, as there might be problems with an already known resolution.

Thursday, September 17, 2009

Poll: On what OS your WebSphere AppServer is installed ?

Poll results for : On what OS your WebSphere AppServer is installed ? , held between Aug 16th 2009 to Sep 16th 2009 and voted my about 86 voters.

Google Chart



You can still continue to vote though:

Poll: On what OS your WebSphere AppServer is installed ?





Tuesday, September 8, 2009

IBM WebSphere related twitters

Here are some of the IBM WebSphere related twitters having interesting tweets on various topics related to IBM WebSphere Product Family.

IBM_WAS IBM WAS SupportIBM WebSphere Application Server support news, updates, and information.
IBM_Commerce IBM Commerce SupportIBM WebSphere Commerce support news, updates, and information.
IBM_WPS IBM WPS SupportIBM WebSphere Process Server support news, updates, and information.
IBM_Monitor IBM Monitor SupportIBM WebSphere Business Monitor Support page.
IBM_Modeler IBM Modeler SupportIBM WebSphere Business Modeler support.
WebSphereBUZZ WebSphere Buzz News.
WebSpherePortal WebSphere PortalYour location for interesting links associated with IBM WebSphere Portal.
WebSphereHelp WebSphere Help, Tips & Tricks.

Monday, September 7, 2009

Book on WebSphere Application Server 7.0 Administration Guide from Packt Publishing


WebSphere Application Server 7.0 Administration Guide from Packt Publishing written by Steven Robinson is one of the few books available on WebSphere 7 Administration. This book is very useful for Websphere 7 Administrators from mid-level to advanced skills to manage Websphere Application Server 7.0. This book covers all the topics from installation, configuration, monitoring to product maintenance. This book has a lot of well written examples with step by step instructions including screenshots of major aspects of server configuration. The chapters are easy to read and you should be able to complete the entire book in few weeks and become a complete WebSphere 7.0 Administration Expert. The book also talk about WebSphere Messaging in chapter 6 in detail on how to configure using the default or WebSphere MQ provider.I would definitely recommend this book. The book is available in both eBook and as a regular printed book. More details about the book can be found in publishers website

Sunday, September 6, 2009

Slowing down your server process does have some benefits

Although lot people are finding various ways to speed up their application servers to improve performance, there are also benefits to slow down your server process especially when testing it to find problems that you won't see in normal scenarios. As you might have seen in your experience that 90% of the time things work well in a normal scenario when there the load on the server is normal, db response throughput is normal, network throughput is optimal , etc. But all of a sudden things start to break when something gets backed up like db fails to respond in an expected time leading to number of concurrent requests due to browser refresh by the user might break the applications due to deadlock or other concurrent related problems. Due to the availability of powerful multiprocessor severs nowadays , requests are executed in terms of milliseconds , hence it would be difficult to catch concurrency related problems unless you recreate the scenario where the requests are taking more time to process. Although one might say this can be simulated by doing a load test on the server, i agree but if there is a problem it would be a overwhelming task and extremely difficult for someone to debug given the amount of requests and objects created during the test, especially if there is a memory leak. Hence the same effect can be achieved by slowing down your server process with just using few concurrent requests which makes things easy to debug and trace.

For (e.g) check this below jsp lrumap.jsp, where it creates a simple LRUMap object, puts it into the session and then serializes it. You will not find any problems with the jsp as long as it runs quickly (usually takes about 10ms is a decent desktop server) with multiple concurrent requests, but if the code slows down due to I/O or some other reason , you will end up with the java.utl.ConcurrentModificationException if the code is executing the serialization part so.writeObject(lmap); and adding of the element lmap.put(lobj[i],new Integer(i)); at the same time even though the LRUMap is synchronizedm, the reason being the serialization code uses an iterator to iterate through the elements in which the iterator is not synchronized which caused the exception. Unless you make the server process to run slow you will never end up catching it until you see it in production during high load conditions where it will become extremely difficult to debug.



How to slow down a process ?


The trick is that you basically limit the CPU usage of the process which will slow down the process as it won't get enough CPU cycles to execute. There is a open source program in Linux CPU Limit can be used for this purpose or you can write a simple shell script where you can send STOP and CONT signal in a loop using the kill command. Although the later is not efficient but it works, but the CPU limit program is much precise even though it'd doing the same but through a C program.

1) Download and install the CPU Limit program.
2) If your System Administrator don't allow then use the shell script,

#!/bin/bash
while [ 1 ]
do
kill -STOP $1
usleep 100000
kill -CONT $1
done

Note using usleep can make the sleep in microseconds where as sleep will sleep in seconds which is not suitable for process executing transactions in milliseconds.

3) find the process id of the process you wanted to slow down.

4) Execute cpulimit -p -l

(e.g) cpulimit -p 11502 -l 10 - this command will allocate max of 10% CPU to the process 11502.

Tuesday, September 1, 2009

Running your own copy of production server instance in your desktop

Although the title seems little strange and scary I will explain to you in this article why it's needed, it's advantages and how you can setup easily without much changes. Being an Administrator and Support Engineer throughout my career i haven't seen an single I.T department having an exact replica of the production and testing/staging environment, there is always some difference between those environments like the most common is the amount of production data is not same as that of staging data which changes the equation of how the application behaves. There are situations where production support engineers won't even have access to staging/testing environments because it's either managed by a different vendor, or because of SOX compliance or due to various security reasons. Being an administrator , the application is kind of a black box compared to the developers where you might not have had much chance to play with it and understand how it really works, most of them you will come know from the word of mouth from the developers which sometimes may not be true in terms of how it's behaving in a production as they are aware only in terms how it worked in their development environment which is usually a standalone server compared to a usual cluster environment in production. During outages, you are more focused on bringing the server backup up instead of finding what caused the issue and most of the time it's too late or you don't have enough time to collect the data. Hence it is necessary in my opinion to have your own production copy , so that you can turn on traces , understand how the application works, understand the symptoms if some services breaks and find ways to fix it, so that when the real problem comes you will be prepared for it and tackle the problem quickly with little or no down time. Although many will disagree and you might want to explain the benefits which out weighs the problems.

You are basically going to run the server with a system proxifier like proxychains and tunneling all connections through the SSH proxy from your dekstop with ease without much modifications due to firewall restrictions. Here are some suggested steps,

1) Tar up your production server installation directory and untar it up in your desktop.

2) Make sure you create any directories or symbolic links that the server references that is not
included as a part of installation directory, like log and config directories.

3) Download and Install system proxifier proxychain .

4) Configure /etc/proxychains.conf to point to the socks server. (e.g) socks5 127.0.0.1 9050

5) If there are DNS name resolution issues follow the instructions Performing UDP tunneling through an SSH connection to setup local dns proxy server or enable proxy_dns property in /etc/proxychains.conf

6) Run a SSH proxy from your desktop , (e.g) ssh -D 9050 user@prod-servername.

7) start the server with proxychains or modify the startup script to include proxychains (e.g) proxychain /root/Desktop/jdk1.6.0_16//bin/java -Djava.util.logging.config.file=/opt/apache-tomcat-6.0.20/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/opt/apache-tomcat-6.0.20/endorsed -classpath :/opt/apache-tomcat-6.0.20/bin/bootstrap.jar -Dcatalina.base=/opt/apache-tomcat-6.0.20 -Dcatalina.home=/opt/apache-tomcat-6.0.20 -Djava.io.tmpdir=/opt/apache-tomcat-6.0.20/temp org.apache.catalina.startup.Bootstrap start
you can get the process string by doing ps -auxww after you normaly started the server. Now your server should be able to start and able to connect through the SSH proxy and proxychains output will show how the connections are made ,
(e.g)
ProxyChains-3.1 (http://proxychains.sf.net)
S-chain-<>-127.0.0.1:9050-<--timeout INFO: Mon Aug 31 22:37:41 PDT 2009: PlatformDetector detected platform: tomcat
S-chain-<>-127.0.0.1:9050-<>--10.23.23.11:1521--<>

8) website's domain/virtualhost mapping to your local ip to access the website in /etc/hosts. (e.g) www.example.com 127.0.0.1