The most important thing in searching a job is your resume/CV. Most of the time we end up copying from others :-). So, i just wanted to share with all of you, how to write your own resume in a better way.
5 Points to remember:
————————–
1) Resume will go to hands of recruiters first, they decide wether to forward to technical team or not
2) Keywords
3) Write what you can offer to the company not what you want
4) make it short (max 2 pages)
5) Make everything readable and clear
Resume order template
—————————
Introductory Statement
Summary of your experience
Skills
Experience
Education and others
Resume Content
——————-
1. Introductory Statement
There are 2 types of initial introductions: The objective for entry level professionals and the headline statement for experienced professionals.
Objective Statement - This introductory statement is primarily used by entry level professionals to target positions in which the job seeker has no experience or limited experience. In this case, you are building a statement that tells the reader what type of position you are targeting.
Headline Statement - This statement should be an overall breakdown of your career experience. It should be a simple, yet compelling statement that clearly explains what you bring to the table.
2. Summary
The summary will follow the introductory statement. The summary will consist of anywhere from 3 to 10 supporting statements that provide more details about your experience and/or training. These statements should reflect key areas that you feel are strong requirements for the job position. The statements should be compelling, detailed, yet easy to follow.
use bulletting here
make it to 4-5 points
try to mention all your strong points and achievements
3. Skills
Mention all your skills divided into sub-topics. If you have just a single skill in a catagory, try to club it into others. Pay attention to the required skills
Middleware:
Operating Systems:
Scripting:
Languages:
4. Experience
The experience section is made up of headings, statements of responsibility and statements of achievement.
The Heading - this should include at minimum:
* Name of the Company you worked for
* Location of the Company
* Your Job Title
* Dates of Employment
Statements of Responsibility - Much like the headline statement in the introduction and summary, you will want to build an opening statement that identifies the overall scope of your responsibilities. The following statements then support the opening statement and provide further details regarding your key duties
Achievements - After developing statements of responsibility, you should now document a few achievements. Your achievements are what set you apart from your competition. They help differentiate your resume from other applicants and they demonstrate that you have been successful in previous positions.
5. Education
————–
Experience is almost always a better seller than education, unless you are in an Academic field. Therefore as you gain more experience, focus less on your experience. With the exception of entry level professionals, the education section should fall below the experience section.
Information that is required:
* The name of the degree or certification
* The institution where you received the degree or training
* The date you received the degree
Others
——–
Professional Affiliations - The Project Management Institute (PMI) is a good example of a high profile organization in the field of Project Management and membership is highly regarded. I would not recommend adding this section if the extent of your professional affiliations is something like…. Member of the South Orange Country Computer Users Club.
Publications - Again this is straightforward. Only provide this information if your work was published within well know publication in your field. If you are highly published, it is often a good idea to create a separate document as an addendum to your resume.
Volunteer Work - Sometimes IT professionals set up significant systems within local organizations. In this case, it may be a good idea to add this content, but it really depends on the extent of your career and the level of effort involved in your volunteer work.
In summary, the technical resume should accomplish these goals:
* Introduce yourself with compelling, detailed information using brief statements that summarize your career.
* Identify your key areas of technical expertise and IT skills sets.
* Document the scope of your work experience.
* Demonstrate your past success through statements of achievement.
* Define your training and education.
* Utilize action verbs and action oriented statements.
* Above all else — GENERATE INTERVIEWS.
funny facts
=======
1. Available for interview
What does this statement mean in your resume? If you are not available for interview why sending it ?
2. References available upon request
references are expected when required; why to write which was expected from employer
3. Too many skills
don’t mention everything you read….that just confuses the interviewer on what exactly know
4. Irrelavent things like your hobbiles, interests
If something is not related to the requirement you are applying for…..better leave it
5. Paragraphs with 10+ lines
who has the time to read what all you wrote? make it short and points wise
******
Example
******
Name
Address email
City/countrt phone#
Middleware administrator specializing in Websphere platform products with experience in installing, configuring and maintaining enterprise production servers in a high available 24×7 environments. A self-starter, adept at moving into new environment and process first-rate communications and collabaration skills
Summery
=======
* Websphere certified (WAS) administrator and good exposure to MQ
* 5years of experience in maintaining websphere environments on unix/linux hosts
* Trained on websphere MQ from IBM
* Good troubleshooting and analytical skills which were appriciated by clients for quick response times
* Ability to guide the team and train team members
Skills
===
Middleware: Websphere application server, Websphere MQ
Operating Systems: Linux and Solaris
Scripting: Shell scripting and python
Security: Sun LDAP and open LDAP
Languages: Java, HTML and C++
Experience
========
XYZ inc, Los Angeles, CA
Websphere administrator Oct2005 - Dec2008
Build and maintain the websphere application server and IBM http servers on a farm of 1000+ servers hosted on solaris machines. providing on demand troubleshooting and consulting for the issues faced in the web hosting environment. Coordinate with development team to implement requirements change management and service improvements.
YYZZ corp , Boston, MA
Middleware Administrator
Responsible for administrating the middleware components ranging from webservers, application serves and directory servers. Deploying applications and configuring them for higher performance. Maintain the ITIL process related documentation and SLA timeleines. Train staff members on websphere nad guide the rookies.
Education
======
Bachelors degree in Science
From Boston University in 2004
with major in Communications
Oct 8, 2009
Sep 10, 2009
Websphere (WAS) Session Replication
What is session?
————————–
* A Session is a series of requests to a servlet, originating from the same user at the same browser
How session works?
——————————
* session ID Allows to keep track of individual users
* Session ID generated on first request and send back to browser with first response.
* Session ID then arrives with each subsequent request
* Cookies, URL rewriting and SSL (if request is on HTTPS) are ways to track the session IDs
Distributed sessions
——————————
Session management can store session-related information in …
* In application server memory (the default). This storage options is knows as in-memory sessions.
* In a database. This storage option is known as database persistent sessions.
* In another WebSphere Application Server instance. This storage option is known as memory-to-memory sessions.
* Distributed sessions are essential for using HTTP sessions for the failover facility
* Plug-in maintains Session affinity by sending requests with session ID to cluster member where that session has been previously created
* On the failure of cluster member, plug-in routes requests to other members
* When cluster member receives a request associated with a session ID that it currently does not have in memory, it can obtain the required session state by accessing the external store (database or memory-to-memory).
Memory-Memory replication
—————————————–
* In Memory-to-Memory session replication, session data from owner server replicates (copies) in one or more other application server using Data Replication Service
=>Data Replication Service (DRS) is an internal WebSphere Application Server component that replicates data. You can configure DRS by creating a replication domain. Replication Domain can be created either manually from Environment page of admin console or automatically at cluster create time.
* This requires creation of a data replication service instance in owner server that communicates to other data replication service instances in remote application servers
* This can be achieved by creating a replication domain and configuring the session manager of cluster members to use memory-to-memory replication.
* A server can run in one of the following three modes:
* Client mode: server only sends copies of sessions it owns
* Server mode: server only stores backup copies of other servers
* Both mode: server sends copies of session it owns and acts as a backup table for sessions owned by other application server
* Two different topologies are possible based on above three modes
* Peer-to-Peer topology
* Client/Server topology
=> Peer-to-Peer topology
* Each server stores a session in it’s own memory and also stores sessions to, and retrieves from, other application servers.
* Each application server acts as client by retrieving session from other servers and acts as server by providing sessions to other application servers
* This is the default configuration and each application server can:
* Host the Web Application leveraging the HTTP Session
* Send Changes to the HTTP Session that it owns
* Receive backup copies of the HTTP session from all of the other servers in the cluster
=>Steps to configure
1. Create replication domain
configure request timeout, encryption and number of replicas
2. go to Servers ->Application servers -> First Cluster member -> Sessionmanagement -> Distributed environment settings -> Memoryto-memory replication
3. Select the replication domain created in first step
4. Select “Both Client and Server” as replication mode
5. Click Ok and Save to master configuration
6. Repeat above steps for all the cluster members
7. Once done, restart the cluster
=>Advantages
* No additional processes and products are required to avoid a single point of failure.
* Reduce the time and cost required to configure and maintain additional processes or products
=>Disadvantages
* It can consume large amounts of memory with many users. This can cause a performance impact
* Does not provide stable configuration for cluster with only 2 members
=>Client/Server topology
* Application Servers act as either a replication Client or a Server
* Replication servers store sessions in there own memory and provide session info to clients.
* Dedicated replication servers just store session but do not respond to users’ requests
* Client application servers send session information to replication servers and retrieve as needed. Clients respond to user requests
* Application servers configured as Server can not host any applications. They act as pure data store for backup sessions and receive updates from Clients
* Backup data is isolated into a separate JVM
* Client replicas will contain only local session data
* Application servers configured as Servers must be started before starting Clients
=>Steps to configure
1. Create replication domain
configure request timeout, encryption and number of replicas
2. go to Servers ->Application servers -> First Cluster member -> Sessionmanagement -> Distributed environment settings -> Memoryto-memory replication
3. configure cluster1 members as client
4. configure cluster2 members as Server
5. start cluster2 first and then cluster1
=>Advantages
* Clearly distinguishes the role of client and server.
* Reduces the consumption of memory on each application server
* Better performance
* Allows recycle of a backup server without affecting the servers running applications
* Better choice if your hardware varies across the cluster
=>Disadvantages
* Additional application servers have to be configured and maintained over and above those that interact with the user
* Need multiple replication servers to avoid a single point of failure.
————————–
* A Session is a series of requests to a servlet, originating from the same user at the same browser
How session works?
——————————
* session ID Allows to keep track of individual users
* Session ID generated on first request and send back to browser with first response.
* Session ID then arrives with each subsequent request
* Cookies, URL rewriting and SSL (if request is on HTTPS) are ways to track the session IDs
Distributed sessions
——————————
Session management can store session-related information in …
* In application server memory (the default). This storage options is knows as in-memory sessions.
* In a database. This storage option is known as database persistent sessions.
* In another WebSphere Application Server instance. This storage option is known as memory-to-memory sessions.
* Distributed sessions are essential for using HTTP sessions for the failover facility
* Plug-in maintains Session affinity by sending requests with session ID to cluster member where that session has been previously created
* On the failure of cluster member, plug-in routes requests to other members
* When cluster member receives a request associated with a session ID that it currently does not have in memory, it can obtain the required session state by accessing the external store (database or memory-to-memory).
Memory-Memory replication
—————————————–
* In Memory-to-Memory session replication, session data from owner server replicates (copies) in one or more other application server using Data Replication Service
=>Data Replication Service (DRS) is an internal WebSphere Application Server component that replicates data. You can configure DRS by creating a replication domain. Replication Domain can be created either manually from Environment page of admin console or automatically at cluster create time.
* This requires creation of a data replication service instance in owner server that communicates to other data replication service instances in remote application servers
* This can be achieved by creating a replication domain and configuring the session manager of cluster members to use memory-to-memory replication.
* A server can run in one of the following three modes:
* Client mode: server only sends copies of sessions it owns
* Server mode: server only stores backup copies of other servers
* Both mode: server sends copies of session it owns and acts as a backup table for sessions owned by other application server
* Two different topologies are possible based on above three modes
* Peer-to-Peer topology
* Client/Server topology
=> Peer-to-Peer topology
* Each server stores a session in it’s own memory and also stores sessions to, and retrieves from, other application servers.
* Each application server acts as client by retrieving session from other servers and acts as server by providing sessions to other application servers
* This is the default configuration and each application server can:
* Host the Web Application leveraging the HTTP Session
* Send Changes to the HTTP Session that it owns
* Receive backup copies of the HTTP session from all of the other servers in the cluster
=>Steps to configure
1. Create replication domain
configure request timeout, encryption and number of replicas
2. go to Servers ->Application servers -> First Cluster member -> Sessionmanagement -> Distributed environment settings -> Memoryto-memory replication
3. Select the replication domain created in first step
4. Select “Both Client and Server” as replication mode
5. Click Ok and Save to master configuration
6. Repeat above steps for all the cluster members
7. Once done, restart the cluster
=>Advantages
* No additional processes and products are required to avoid a single point of failure.
* Reduce the time and cost required to configure and maintain additional processes or products
=>Disadvantages
* It can consume large amounts of memory with many users. This can cause a performance impact
* Does not provide stable configuration for cluster with only 2 members
=>Client/Server topology
* Application Servers act as either a replication Client or a Server
* Replication servers store sessions in there own memory and provide session info to clients.
* Dedicated replication servers just store session but do not respond to users’ requests
* Client application servers send session information to replication servers and retrieve as needed. Clients respond to user requests
* Application servers configured as Server can not host any applications. They act as pure data store for backup sessions and receive updates from Clients
* Backup data is isolated into a separate JVM
* Client replicas will contain only local session data
* Application servers configured as Servers must be started before starting Clients
=>Steps to configure
1. Create replication domain
configure request timeout, encryption and number of replicas
2. go to Servers ->Application servers -> First Cluster member -> Sessionmanagement -> Distributed environment settings -> Memoryto-memory replication
3. configure cluster1 members as client
4. configure cluster2 members as Server
5. start cluster2 first and then cluster1
=>Advantages
* Clearly distinguishes the role of client and server.
* Reduces the consumption of memory on each application server
* Better performance
* Allows recycle of a backup server without affecting the servers running applications
* Better choice if your hardware varies across the cluster
=>Disadvantages
* Additional application servers have to be configured and maintained over and above those that interact with the user
* Need multiple replication servers to avoid a single point of failure.
Sep 8, 2009
Its time to step it up and learn
Well…
The recession is on the road to recovery ! Does this period of recession helped you ? I guess so.
The recession is on the road to recovery ! Does this period of recession helped you ? I guess so.
If you are trying to switch to a new job now… just stop thinking of it. I fell this is not at all the right time to go for a jump. Watch out the Job Market…slowly coming to life. That should not be our point of interest. Our interest is what skills are gaining the market and are in demand?
A recent survey on market showing that from the development perspective, .Net will come good after the recovery. Right now, though companies are recruiting for .net seems the market is not reaching the demand. Seems like java development jobs will slow down for sometime. From the administration view… Looks like IBM products are gaining ground in this recession. Even oracle fusion middleware is also comes good but not as fast as IBM’s. If you are on Operating systems, its time to upgrade you to new level or with a new add-on products like some monitoring tool, version controllers etc
Might be many of you are observing/trying all this recession period for a new job and some of you might already got a new job. What did you make out of the present job market ? Its obvious that, people with multiple related skills are in demand. Example, now very less companies are taking people with only WAS skill or MQ skills. If you are MQ admin, you should know MB as well similarly a WAS admin should know MQ or linux. Now just think, where are you now? Still stuck to a single skill ? This might work out as long as you stick to your present employer but if you want see the world outside, then ??
So which skills to gain? Keep observing the jobs posted on the job portals and compare the Job descriptions with your knowledge. Say you are a websphere admin, look out what other skills the employers are demanding. The main complaint from many employers in this recession period is that - ‘though they want to recruit people there is shortage of the combination skills in the market.
“Cost Cutting”, which drives all the companies after the recovery from the recession. So what is its effect on us ? Obviously its not like the olden days where there are 2 people to do 2 different tasks, now there will be only one who can do both tasks. Are you ready for this kind of challenge?
Now lets talk about your present employer
————————————————–------------------
have ever asked your self any of these questions?
-What type of new projects my company is getting?
-What is my present company’s plan for next 1-2 years?
-Do my company have the required skill to match the demand of the upcoming market?
-What is your company’s plan to bring new skills into the organization?
-How often they do the ‘technical assessment’ of the existing projects?
-what is the existing customer’s feedback or view to continue the business for some more time?
-What will i gain along with this company down the lane in next 2yrs?
————————————————–------------------
have ever asked your self any of these questions?
-What type of new projects my company is getting?
-What is my present company’s plan for next 1-2 years?
-Do my company have the required skill to match the demand of the upcoming market?
-What is your company’s plan to bring new skills into the organization?
-How often they do the ‘technical assessment’ of the existing projects?
-what is the existing customer’s feedback or view to continue the business for some more time?
-What will i gain along with this company down the lane in next 2yrs?
Any positive answers?
You should know what’s the plan of your company/manager about your career . Its not just you who has to learn and grow with the technology and have a good future plan. Its the responsibility of your company as well to grow with the technology and make sure that their employees are meeting the expectations of the clients. Will it happen in real-time?
Well… its all depends on you. Have a clear idea on what you want to learn and how the technology is growing. Then compare with your company to see, how is it compared to the market and what are your options to have a hand on the new technologies that are in demand. When and how can you learn them? What does your company provides for you, to achieve your goals. If the answer to this paragraph is +ve, then don’t be in a hurry to make a move now. The good time are ahead. If the answer is -ve, its the best time to step it up. Learn things and wait for the new year.
Take this example.
How do buy a new mobile now a days?
You need SMS, MMS, WAP, GPS, Camera, MP3 player, Video, Wireless and may more… All the mobile manufacturers also coming up with those features, though its costly, why ? Simple reason is they are in demand and some of them are essential for a modern mobile phone.
Same with our case, have an idea on the technologies that you should be, as per the present job market demand. You always have good times around…….your hard work pays.
Websphere (WAS) Dynamic Caching
* Dynamic Cache supports caching of Java servlets, JavaServer Pages (JSP), WebSphere command objects, Web services objects, and Java objects.
* The concept of caching static information in a browser, proxy or a webserver provides an effective way to reduce network and processing requirements. A larger overhead of many web applications is related to the serving, not of static content, but of dynamic content based on user input and retrieval of data from backend resources such as databases.
How to enable Dynamic Cache
* Dynamic cache is enabled by default on V6.1 WebSphere AppServers.
* To enable Servlet and JSP caching from the admin console, navigate to the web container
Servers –> Application Servers -> select server -> webcontainer settings –> webcontainer
* Check ‘Enable servlet caching’
* Save and restart the Application Server to put the changes into effect.
Specify what to be catched
- Now servlet caching is enabled, if is necessary to define which dynamic content will be cached and the rules by which it will be cached or invalidated. servlet and JSP caching will be policy based using the cachespec.xml file. The preferred location for the cachespec.xml file is within the web applications WEB-INF folder.
While the timeout directive dictates how long content can remain in cache before being refreshed, the Inactivity directive can cause a refresh prior to the timeout when a page is not used frequently.
The consume-subfragments property tells the cache not to stop saving content when it includes a child servlet. The parent entry will include all the content from all fragments in its cache entry, resulting in one big cache entry.
Use the element to tell the cache to stop consuming for the excluded fragment and instead, create a placeholder for the include or forward.
A dependencyID identifies a cache entries dependency based on certain factors, such that when those factors occur they trigger an invalidation of all the cache entries that share this dependency.
How it works?
- The first request will result in a cache MISS. Full processing takes place for Time.jsp. The response is returned to the browser but also loaded into cache.
- Subsequent requests for Time.jsp result in a cache HIT until the cached copy of Time.jsp is invalidated.
Monitoring Dynamic cache
* Once Dynamic caching is configured, and dynamic content is cached, the content of the cache can be examined and monitored using the cachemonitor.
* An enterprise application called CacheMonitor is provided with WebSphere Application server. It is available in the folder/installableApps and called CacheMonitor.ear.
Disk Offload
* By default, when the number of cache entries reaches the configured limit for a given application server, cache entries are removed from the memory cache, allowing newer entries to be stored in the cache. Use disk offload to copy the cache entries that are being removed from the memory cache to disk for potential future access. Disk offload is configured via the adminconsole either globally or for a specific cache instance.
Cache Instances
* Since different webapplications or pages may have different caching requirements, unique cache instances can be created for each. This allows applications to have greater flexibility and better tuning of cache resources.
* The characteristics of each servlet cache instance are a unique jndi name, disk offload policies, cache configuration and performance parameters.
Configure a new cache instance
goto Resources –> Cache Instances –> Servlet Cache Instance –> new
* A jndi name must be given to the cache instance which will be used to refer back to the instance in cachespec.xml.
* Check ‘Enable disk offload’ and specify a disk off load location, cache size and cache entry limits.
Cache Invalidation
* It is essential that timely invalidations of cached content take place for the integrity of the website.
Mechanisms for invalidation are:
-timeout or inactivity directives within cachespec.xml
-group-based invalidation mechanism through dependency IDs.
-Programmatic invalidation via the cache API 'com.ibm.websphere.cache.*’
-The CacheMonitor
Some Tips
* WebSphere Application Server uses JVM memory to store cached objects. Therefore, it is important to know how much memory can be allocated for the cache and based on this information you can set the cache size to the proper value.
* Increase the priority of cache entries that are expensive to regenerate.
* Modify timeout of entries so that they stay in memory as long as they are valid.
* If the estimated total size of all cached objects is bigger than the available memory, you can enable the disk offload option.
* Increase the cache size if memory allows.
* The concept of caching static information in a browser, proxy or a webserver provides an effective way to reduce network and processing requirements. A larger overhead of many web applications is related to the serving, not of static content, but of dynamic content based on user input and retrieval of data from backend resources such as databases.
How to enable Dynamic Cache
* Dynamic cache is enabled by default on V6.1 WebSphere AppServers.
* To enable Servlet and JSP caching from the admin console, navigate to the web container
Servers –> Application Servers -> select server -> webcontainer settings –> webcontainer
* Check ‘Enable servlet caching’
* Save and restart the Application Server to put the changes into effect.
Specify what to be catched
- Now servlet caching is enabled, if is necessary to define which dynamic content will be cached and the rules by which it will be cached or invalidated. servlet and JSP caching will be policy based using the cachespec.xml file. The preferred location for the cachespec.xml file is within the web applications WEB-INF folder.
While the timeout directive dictates how long content can remain in cache before being refreshed, the Inactivity directive can cause a refresh prior to the timeout when a page is not used frequently.
The consume-subfragments property tells the cache not to stop saving content when it includes a child servlet. The parent entry will include all the content from all fragments in its cache entry, resulting in one big cache entry.
Use the
A dependencyID identifies a cache entries dependency based on certain factors, such that when those factors occur they trigger an invalidation of all the cache entries that share this dependency.
How it works?
- The first request will result in a cache MISS. Full processing takes place for Time.jsp. The response is returned to the browser but also loaded into cache.
- Subsequent requests for Time.jsp result in a cache HIT until the cached copy of Time.jsp is invalidated.
Monitoring Dynamic cache
* Once Dynamic caching is configured, and dynamic content is cached, the content of the cache can be examined and monitored using the cachemonitor.
* An enterprise application called CacheMonitor is provided with WebSphere Application server. It is available in the folder
Disk Offload
* By default, when the number of cache entries reaches the configured limit for a given application server, cache entries are removed from the memory cache, allowing newer entries to be stored in the cache. Use disk offload to copy the cache entries that are being removed from the memory cache to disk for potential future access. Disk offload is configured via the adminconsole either globally or for a specific cache instance.
Cache Instances
* Since different webapplications or pages may have different caching requirements, unique cache instances can be created for each. This allows applications to have greater flexibility and better tuning of cache resources.
* The characteristics of each servlet cache instance are a unique jndi name, disk offload policies, cache configuration and performance parameters.
Configure a new cache instance
goto Resources –> Cache Instances –> Servlet Cache Instance –> new
* A jndi name must be given to the cache instance which will be used to refer back to the instance in cachespec.xml.
* Check ‘Enable disk offload’ and specify a disk off load location, cache size and cache entry limits.
Cache Invalidation
* It is essential that timely invalidations of cached content take place for the integrity of the website.
Mechanisms for invalidation are:
-timeout or inactivity directives within cachespec.xml
-group-based invalidation mechanism through dependency IDs.
-Programmatic invalidation via the cache API 'com.ibm.websphere.cache.*’
-The CacheMonitor
Some Tips
* WebSphere Application Server uses JVM memory to store cached objects. Therefore, it is important to know how much memory can be allocated for the cache and based on this information you can set the cache size to the proper value.
* Increase the priority of cache entries that are expensive to regenerate.
* Modify timeout of entries so that they stay in memory as long as they are valid.
* If the estimated total size of all cached objects is bigger than the available memory, you can enable the disk offload option.
* Increase the cache size if memory allows.
Sep 7, 2009
Websphere Application Server v7: What's new ?
WebSphere Application Server V7 builds upon the powerful and stable core of previous releases with several new features and enhancements. In addition to support for the latest standards and programming models, V7 contains key improvements in the areas of systems management, installation, and security.
whats new?
* Java EE 5
* Dependency injection
* Java Persistence API
* Systems management
* Intelligent provisioning
* Administrative agent
* Job manager
* Web services
* Messaging
* Centralized installation
* Business level applications
* Security
* Auditing
* Kerbero
Java EE 5
The most notable supported standard in WebSphere Application Server V7 is Java™ Platform, Enterprise Edition (Java EE) 5. WebSphere Application Server V7 provides complete support for the Java EE 5 specification, including the Web services and EJB 3.0 functions that were previously available as feature packs in V6.1. WebSphere Application Server V7 also introduces support for Java Platform, Standard Edition (Java SE) 6.
Dependency injection
Developer productivity is further enhanced when it’s time to override the defaults, since this can be accomplished quickly and simply using annotations rather than writing code. Annotations are used in conjunction with a programming pattern known as dependency injection, or Inversion of Control (IoC), in which the application code simply declares variables and annotates them to indicate whatever is needed, and then the container “injects” the specified object or resource references.
Java Persistence API
Another aspect to the simplification of the programming model in Java EE 5 is the ability to develop EJB components as Plain Old Java Objects (POJOs). Simplifying EJB development even further is the Java Persistence API (JPA), which enables entities to be created using annotated POJOs. Aside from making EJB development and usage even easier, this also enables Java SE developers to quickly learn Java EE and develop enterprise applications.
Web services
The improvements to the Java EE 5 programming model aren’t limited to EJB development. Web services development is also greatly simplified via annotations. The JAX-WS implementation in WebSphere Application Server V7 also provides support for SOAP 1.2, as well as for generic XML or HTTP as a protocol binding, which enables the creation of WS clients and WS providers that do not use SOAP for their wire level message format.
Another important addition in WebSphere Application Server V7 is its support for Message Transmission Optimization Mechanism (MTOM), an improved method for sending binary attachments. MTOM is the preferred attachment mechanism for non-Java EE-based Web services, so support for MTOM improves the interoperability between Java EE Web services and non-Java EE Web services.
Systems management
Systems management is another major area enhanced in WebSphere Application Server V7, with a number of new management and administration options to help you implement a more flexible, scalable, and asynchronous administrative topology, and to help you reduce cost and increase effectiveness as well:
Intelligent provisioning
First on the list is intelligent provisioning by the WebSphere Application Server runtime, which selects only the run time function needed for an application, reducing both memory footprint and application server startup time. Each application is examined by WebSphere Application Server at application installation time to generate an activation plan; at run time, the server starts only those components that are required by the activation plan.
WebSphere Application Server V7 contains support for a Web/JDBC application scenario in which only the Web container and core run time components are started. This is in contrast to V6.1, in which the EJB container, SIP container, and Web services runtime would also have been started. This capability is also used in fixed function servers (for example, WebSphere Application Server proxy server) to help reduce the memory footprint, and is designed for extension by other WebSphere products that run on top of WebSphere Application Server.
Additional run time footprint reductions are delivered in the form of the Java SE 6 implementation that ships with WebSphere Application Server V7. The shared class cache that was introduced in IBM’s Java SE 5 implementation has been improved so that the cache can now be persistent.
Another improvement in IBM’s Java SE 6 is the use of compressed references (or pointer compression) in 64-bit WebSphere Application Server JVMs. The use of compressed references can provide a very significant reduction in the process footprint of a 64-bit JVM, when previously compared to a 32-bit JVM. Prior to IBM’s Java SE 6 implementation, it wasn’t unusual for a 64-bit heap to be 1.7 to 2 times the size of an equivalent 32-bit heap.
Administrative agent
Flexible management is an improvement that can help reduce the cost of administering large deployments in several ways. Flexible management changes this by separating most of the administrative components from the application server runtime. Now, each application server is no longer a single point of management. This is accomplished with a separate administration process for (base) WebSphere Application Servers know as the administrative agent.
You might wonder if moving the administration function from the application server to the admin agent provides more capability. The answer lies in the fact that an admin agent can manage multiple WebSphere Application Server (base) instances on a single machine.
When using an admin agent, as the number of application server instances increases the duplication of the administration footprint (for each application server) is eliminated. Further, since the admin agent can manage all the application server instances on a machine, there’s only one set of remote administration ports to remember (those for the admin agent), as opposed to trying to manage all the separate administration ports associated with each application server.
When working with the admin agent, remember that:
* The admin agent can only manage the application servers that are on the same machine as the admin agent.
* Although the admin agent can manage multiple application servers, each application server is managed individually. In other words, you would log into the admin agent to change the configuration of server1, log out, then log on to server2, and so on.
* The admin agent only provides management of these application servers (and their applications) — it does not provide for clustering and failover. For clustering and failover and centralized application management, you still need WebSphere Application Server Network Deployment.
Job manager
The job manager is another aspect of flexible management that is available in WebSphere Application Server Network Deployment . The job manager in Network Deployment addresses the limitations inherent in the current management architecture by adopting a loose management coupling architecture: rather than synchronously controlling a number of remote endpoints (node agents), the job manager coordinates management across a group of endpoints by providing an asynchronous job management capability across a number of nodes. The management model relies on the submission of management jobs to these remote endpoint, which can be either a WebSphere Application Server (base) admin agent or Network Deployment deployment manager. In turn, the admin agent or the deployment manager is what actually executes the jobs that update the configuration, start or stop applications, or perform a variety of other common administrative tasks.
Web services
Another important new systems management capability in V7 is in the area of Web services, in addition to the programming model improvements mentioned earlier. Web service policy sets are mechanisms provided by WebSphere Application Server V7 for centrally defining various quality of service polices that you might want to apply to Web services that are already deployed. There are two types of policy sets:
* Application policy sets are used for business-related assertions, such as business operations that are defined in the WSDL file.
* System policy sets are used for non-business-related system messages, such as messages that are defined in specifications that apply QoS policies. Examples would include security token (RST) messages that are defined in WS-Trust, or the creation of sequence messages that are defined in WS-Reliable Messaging metadata.
Rather then defining individual policies and applying them individually to each Web service, policy sets can be applied once to all Web service applications to which they are applicable, thus insuring a uniform quality of service for a given type of Web service
Messaging
Beyond the Web services improvements in WebSphere Application Server V7, there are also improvements to a related SOA component: messaging. New administrative wizards for System Integration Bus (SIBus) configuration are provided for configuring a cluster bus member and a foreign bus connection, as well as new panels for SIBus authorizations, WebSphere MQ JCA Resource Adapter configuration, and for inspecting an application’s use of SIBus resources.
Centralized installation
Network Deployment also adds the capability to perform centralized installation from the deployment manager to remote nodes. This enables a single installation to the deployment manager to be pushed out as an installation package from the deployment manager to a series of endpoints. The endpoint can be either a node that is not part of a Network Deployment cell (in which case Network Deployment can be installed) or an existing Network Deployment node that might need a fix pack.
Business level applications
Another new function in WebSphere Application Server V7 is a the notion of an “application” beyond J2EE™, or a business level application (BLA). This is a new administration concept that expands upon what was previously provided by J2EE. Cases where this can be of value include those where an application:
* Is composed of multiple packages.
* Contains additional libraries, or non-Java EE artifacts.
* Includes artifacts that run on heterogeneous (WebSphere and non-WebSphere) runtimes.
* Is defined in a recursive manner; for example, if an application includes other applications.
Security
Security management and auditing improvements are also a significant portion of what’s new in WebSphere Application Server V7. Perhaps the most prominent change is the capability to create multiple security domains within a single WebSphere Application Server cell. Each security domain can have its own user population (and underlying repository), and, additionally, the application domain can be separated from the administrative domain. Not only can each domain have its own separate user population, but each domain can also be customized with a separate security configuration — for example, JAAS login configuration, TAI, authorization provider, JCA authentication data, and auditing — in addition to the current application server level security configuration options. The scope of the domain is variable and can range from a cell, cluster, or node to a node group or application server.
Auditing
Another security enhancement is the option to generate security auditing records of WebSphere Application Server administrative actions. These actions can be security configuration changes, key and certificate management, access control policy changes, bus and other system resources management, and so on. This feature enables you to hold administrative users accountable for configuration and run time changes.
Further, the review and control of audit records and audit configurations is entrusted to a new auditor role, which enables the separation of administrative user privileges, in that an administrator cannot change audit policy and cannot view audit records, nor can an auditor change WebSphere configuration and run time state.
Kerberos
WebSphere Application Server V7 provides support for Kerberos Authentication, which can be used in a variety of single sign-on scenarios. The Kerberos support in V7 expands on the SPNEGO TAI support in V6.1 to provide better interoperability and identity propagation with other applications that support Kerberos authentication (such as IBM DB2®, .NET®, and others).
whats new?
* Java EE 5
* Dependency injection
* Java Persistence API
* Systems management
* Intelligent provisioning
* Administrative agent
* Job manager
* Web services
* Messaging
* Centralized installation
* Business level applications
* Security
* Auditing
* Kerbero
Java EE 5
The most notable supported standard in WebSphere Application Server V7 is Java™ Platform, Enterprise Edition (Java EE) 5. WebSphere Application Server V7 provides complete support for the Java EE 5 specification, including the Web services and EJB 3.0 functions that were previously available as feature packs in V6.1. WebSphere Application Server V7 also introduces support for Java Platform, Standard Edition (Java SE) 6.
Dependency injection
Developer productivity is further enhanced when it’s time to override the defaults, since this can be accomplished quickly and simply using annotations rather than writing code. Annotations are used in conjunction with a programming pattern known as dependency injection, or Inversion of Control (IoC), in which the application code simply declares variables and annotates them to indicate whatever is needed, and then the container “injects” the specified object or resource references.
Java Persistence API
Another aspect to the simplification of the programming model in Java EE 5 is the ability to develop EJB components as Plain Old Java Objects (POJOs). Simplifying EJB development even further is the Java Persistence API (JPA), which enables entities to be created using annotated POJOs. Aside from making EJB development and usage even easier, this also enables Java SE developers to quickly learn Java EE and develop enterprise applications.
Web services
The improvements to the Java EE 5 programming model aren’t limited to EJB development. Web services development is also greatly simplified via annotations. The JAX-WS implementation in WebSphere Application Server V7 also provides support for SOAP 1.2, as well as for generic XML or HTTP as a protocol binding, which enables the creation of WS clients and WS providers that do not use SOAP for their wire level message format.
Another important addition in WebSphere Application Server V7 is its support for Message Transmission Optimization Mechanism (MTOM), an improved method for sending binary attachments. MTOM is the preferred attachment mechanism for non-Java EE-based Web services, so support for MTOM improves the interoperability between Java EE Web services and non-Java EE Web services.
Systems management
Systems management is another major area enhanced in WebSphere Application Server V7, with a number of new management and administration options to help you implement a more flexible, scalable, and asynchronous administrative topology, and to help you reduce cost and increase effectiveness as well:
Intelligent provisioning
First on the list is intelligent provisioning by the WebSphere Application Server runtime, which selects only the run time function needed for an application, reducing both memory footprint and application server startup time. Each application is examined by WebSphere Application Server at application installation time to generate an activation plan; at run time, the server starts only those components that are required by the activation plan.
WebSphere Application Server V7 contains support for a Web/JDBC application scenario in which only the Web container and core run time components are started. This is in contrast to V6.1, in which the EJB container, SIP container, and Web services runtime would also have been started. This capability is also used in fixed function servers (for example, WebSphere Application Server proxy server) to help reduce the memory footprint, and is designed for extension by other WebSphere products that run on top of WebSphere Application Server.
Additional run time footprint reductions are delivered in the form of the Java SE 6 implementation that ships with WebSphere Application Server V7. The shared class cache that was introduced in IBM’s Java SE 5 implementation has been improved so that the cache can now be persistent.
Another improvement in IBM’s Java SE 6 is the use of compressed references (or pointer compression) in 64-bit WebSphere Application Server JVMs. The use of compressed references can provide a very significant reduction in the process footprint of a 64-bit JVM, when previously compared to a 32-bit JVM. Prior to IBM’s Java SE 6 implementation, it wasn’t unusual for a 64-bit heap to be 1.7 to 2 times the size of an equivalent 32-bit heap.
Administrative agent
Flexible management is an improvement that can help reduce the cost of administering large deployments in several ways. Flexible management changes this by separating most of the administrative components from the application server runtime. Now, each application server is no longer a single point of management. This is accomplished with a separate administration process for (base) WebSphere Application Servers know as the administrative agent.
You might wonder if moving the administration function from the application server to the admin agent provides more capability. The answer lies in the fact that an admin agent can manage multiple WebSphere Application Server (base) instances on a single machine.
When using an admin agent, as the number of application server instances increases the duplication of the administration footprint (for each application server) is eliminated. Further, since the admin agent can manage all the application server instances on a machine, there’s only one set of remote administration ports to remember (those for the admin agent), as opposed to trying to manage all the separate administration ports associated with each application server.
When working with the admin agent, remember that:
* The admin agent can only manage the application servers that are on the same machine as the admin agent.
* Although the admin agent can manage multiple application servers, each application server is managed individually. In other words, you would log into the admin agent to change the configuration of server1, log out, then log on to server2, and so on.
* The admin agent only provides management of these application servers (and their applications) — it does not provide for clustering and failover. For clustering and failover and centralized application management, you still need WebSphere Application Server Network Deployment.
Job manager
The job manager is another aspect of flexible management that is available in WebSphere Application Server Network Deployment . The job manager in Network Deployment addresses the limitations inherent in the current management architecture by adopting a loose management coupling architecture: rather than synchronously controlling a number of remote endpoints (node agents), the job manager coordinates management across a group of endpoints by providing an asynchronous job management capability across a number of nodes. The management model relies on the submission of management jobs to these remote endpoint, which can be either a WebSphere Application Server (base) admin agent or Network Deployment deployment manager. In turn, the admin agent or the deployment manager is what actually executes the jobs that update the configuration, start or stop applications, or perform a variety of other common administrative tasks.
Web services
Another important new systems management capability in V7 is in the area of Web services, in addition to the programming model improvements mentioned earlier. Web service policy sets are mechanisms provided by WebSphere Application Server V7 for centrally defining various quality of service polices that you might want to apply to Web services that are already deployed. There are two types of policy sets:
* Application policy sets are used for business-related assertions, such as business operations that are defined in the WSDL file.
* System policy sets are used for non-business-related system messages, such as messages that are defined in specifications that apply QoS policies. Examples would include security token (RST) messages that are defined in WS-Trust, or the creation of sequence messages that are defined in WS-Reliable Messaging metadata.
Rather then defining individual policies and applying them individually to each Web service, policy sets can be applied once to all Web service applications to which they are applicable, thus insuring a uniform quality of service for a given type of Web service
Messaging
Beyond the Web services improvements in WebSphere Application Server V7, there are also improvements to a related SOA component: messaging. New administrative wizards for System Integration Bus (SIBus) configuration are provided for configuring a cluster bus member and a foreign bus connection, as well as new panels for SIBus authorizations, WebSphere MQ JCA Resource Adapter configuration, and for inspecting an application’s use of SIBus resources.
Centralized installation
Network Deployment also adds the capability to perform centralized installation from the deployment manager to remote nodes. This enables a single installation to the deployment manager to be pushed out as an installation package from the deployment manager to a series of endpoints. The endpoint can be either a node that is not part of a Network Deployment cell (in which case Network Deployment can be installed) or an existing Network Deployment node that might need a fix pack.
Business level applications
Another new function in WebSphere Application Server V7 is a the notion of an “application” beyond J2EE™, or a business level application (BLA). This is a new administration concept that expands upon what was previously provided by J2EE. Cases where this can be of value include those where an application:
* Is composed of multiple packages.
* Contains additional libraries, or non-Java EE artifacts.
* Includes artifacts that run on heterogeneous (WebSphere and non-WebSphere) runtimes.
* Is defined in a recursive manner; for example, if an application includes other applications.
Security
Security management and auditing improvements are also a significant portion of what’s new in WebSphere Application Server V7. Perhaps the most prominent change is the capability to create multiple security domains within a single WebSphere Application Server cell. Each security domain can have its own user population (and underlying repository), and, additionally, the application domain can be separated from the administrative domain. Not only can each domain have its own separate user population, but each domain can also be customized with a separate security configuration — for example, JAAS login configuration, TAI, authorization provider, JCA authentication data, and auditing — in addition to the current application server level security configuration options. The scope of the domain is variable and can range from a cell, cluster, or node to a node group or application server.
Auditing
Another security enhancement is the option to generate security auditing records of WebSphere Application Server administrative actions. These actions can be security configuration changes, key and certificate management, access control policy changes, bus and other system resources management, and so on. This feature enables you to hold administrative users accountable for configuration and run time changes.
Further, the review and control of audit records and audit configurations is entrusted to a new auditor role, which enables the separation of administrative user privileges, in that an administrator cannot change audit policy and cannot view audit records, nor can an auditor change WebSphere configuration and run time state.
Kerberos
WebSphere Application Server V7 provides support for Kerberos Authentication, which can be used in a variety of single sign-on scenarios. The Kerberos support in V7 expands on the SPNEGO TAI support in V6.1 to provide better interoperability and identity propagation with other applications that support Kerberos authentication (such as IBM DB2®, .NET®, and others).
Websphere (WAS) Plug-in
WAS-Plugin
WAS - Plug-In
* Plug-in is a glue between a Web Server and WebSphere Application Server
* Plug-in’s primary responsibility is to forward HTTP requests to the WebSphere Application Server
* The web server plug-in is developed native C language
* This library resides on the Web server machine and is loaded by the Web server startup process.
* To understand it in a betterway, think of WebSphere plug-in as an “agent”
using the HTTP protocol, redirecting HTTP requests from the WebServer to the application server
Plug-in Operation:
* The plug-in “sends” HTTP requests, and acts as an HTTP client.
* The application server receives those requests, and is therefore an HTTP Server.
* The component inside the application server which does the job of an HTTP Server is known as the HttpTransport.
* The HttpTransport of the appserver, listens on specific ports for HTTP (ie. 9080) and for HTTPS (ie. 9443).
* If there are multiple application server on the same node, they must be configured to use unique port numbers.
some components invloved with Plugin
* httpd.conf: The default configuration file of the IBM HTTP Server (IHS) Web server.
* Plug-in: DLL residing on the same system as the Web server is loaded into memory by the Web server during startup and runs inside the same process as the Web server.
* plugin-cfg.xml: This is the web server plug-in configuration file and contains information about which URLs should be serviced by WebSphere.
* HttpTransport: This component's job is to accept the HTTP request from the plug-in, and then forward it to the Web container.
* Web container: It is responsible for processing data inside the request and giving the response data back to the plug-in.
Plugin-cfg.xml file
* plugin-cfg.xml file is created by clicking the “Generate Plug-in” button on the web servers page of the WebSphere administrative console.
* Also GenPluginCfg.sh/bat script can be used to “generate” a plug-in configuration file called plugin-cfg.xml
* The GenPluginCfg.sh/bat picks information from AppServer Server configuration xml files to populate the plugin-cfg.xml file
* If the web server is on a different system than WebSphere Application Server, the plugin config (plugin-cfg.xml file) must be copied (propagated) from WAS to the web server system.
=> Troubleshooting
Important files for troubleshooting
From IBM Http Server (IHS):
* httpd.conf
* error.log
* access.log
From Plug-in:
* plugin-cfg.xml
* http_plugin.log
From WebSphere Application Server (WAS):
* SystemOut.log
* Trace.log
=> Load Balancing
Round Robin method
* For the first request (after web server start-up), the server will be chosen randomly.
* After that, the plug-in will use the next server in the list and so on…
* Each time a server is “picked”, the load balance weight is decremented by one.
* Any server with a weight below 0 will no longer be used for new requests. But, affinity requests will still go through.
* When all servers have a weight of less than 0, the plug-in will “reset” the weights to the starting values.
* By default affinity requests do NOT cause the plugin to decrement the weight of the server. This can lead to an uneven distribution when there are many affinity requests. To resolve the affinity problem use this option: IgnoreAffinityRequests="false"
Random
* For all non-affinity requests, the server is “picked” randomly.
* The affinity requests are sent to the matching clone id.
* LoadBalance “weight” is not used at all in the Random case.
=> Common Issues with Plug-In
404 error
* Usually a 404 (page not found) error in the response means that the requested URI is not in the Plug-in config, and did not match. The request was handled by the web server instead, but the file does not exist there either, so the web server sends a HTTP 404 error back to the browser.
* Also, it is possible to get a 404 error from the WAS server itself. If the plug-in does match and does send the request to the WAS server, but that application is currently stopped, the trace will show a 404 error coming back in the response from the server. So the plug-in sends the 404 error back to the browser.
500 Error
* If the request is matched by the plug-in and is sent to the WAS server, but the server is unresponsive or down, the plug-in will send an HTTP 500 error, which will show up as “Internal Server Error” in the browser.
* If there are multiple servers in the ServerCluster, the plug-in will try all of the servers before sending the 500 error to the browser.
WAS - Plug-In
* Plug-in is a glue between a Web Server and WebSphere Application Server
* Plug-in’s primary responsibility is to forward HTTP requests to the WebSphere Application Server
* The web server plug-in is developed native C language
* This library resides on the Web server machine and is loaded by the Web server startup process.
* To understand it in a betterway, think of WebSphere plug-in as an “agent”
using the HTTP protocol, redirecting HTTP requests from the WebServer to the application server
Plug-in Operation:
* The plug-in “sends” HTTP requests, and acts as an HTTP client.
* The application server receives those requests, and is therefore an HTTP Server.
* The component inside the application server which does the job of an HTTP Server is known as the HttpTransport.
* The HttpTransport of the appserver, listens on specific ports for HTTP (ie. 9080) and for HTTPS (ie. 9443).
* If there are multiple application server on the same node, they must be configured to use unique port numbers.
some components invloved with Plugin
* httpd.conf: The default configuration file of the IBM HTTP Server (IHS) Web server.
* Plug-in: DLL residing on the same system as the Web server is loaded into memory by the Web server during startup and runs inside the same process as the Web server.
* plugin-cfg.xml: This is the web server plug-in configuration file and contains information about which URLs should be serviced by WebSphere.
* HttpTransport: This component's job is to accept the HTTP request from the plug-in, and then forward it to the Web container.
* Web container: It is responsible for processing data inside the request and giving the response data back to the plug-in.
Plugin-cfg.xml file
* plugin-cfg.xml file is created by clicking the “Generate Plug-in” button on the web servers page of the WebSphere administrative console.
* Also GenPluginCfg.sh/bat script can be used to “generate” a plug-in configuration file called plugin-cfg.xml
* The GenPluginCfg.sh/bat picks information from AppServer Server configuration xml files to populate the plugin-cfg.xml file
* If the web server is on a different system than WebSphere Application Server, the plugin config (plugin-cfg.xml file) must be copied (propagated) from WAS to the web server system.
=> Troubleshooting
Important files for troubleshooting
From IBM Http Server (IHS):
* httpd.conf
* error.log
* access.log
From Plug-in:
* plugin-cfg.xml
* http_plugin.log
From WebSphere Application Server (WAS):
* SystemOut.log
* Trace.log
=> Load Balancing
Round Robin method
* For the first request (after web server start-up), the server will be chosen randomly.
* After that, the plug-in will use the next server in the list and so on…
* Each time a server is “picked”, the load balance weight is decremented by one.
* Any server with a weight below 0 will no longer be used for new requests. But, affinity requests will still go through.
* When all servers have a weight of less than 0, the plug-in will “reset” the weights to the starting values.
* By default affinity requests do NOT cause the plugin to decrement the weight of the server. This can lead to an uneven distribution when there are many affinity requests. To resolve the affinity problem use this option: IgnoreAffinityRequests="false"
Random
* For all non-affinity requests, the server is “picked” randomly.
* The affinity requests are sent to the matching clone id.
* LoadBalance “weight” is not used at all in the Random case.
=> Common Issues with Plug-In
404 error
* Usually a 404 (page not found) error in the response means that the requested URI is not in the Plug-in config, and did not match. The request was handled by the web server instead, but the file does not exist there either, so the web server sends a HTTP 404 error back to the browser.
* Also, it is possible to get a 404 error from the WAS server itself. If the plug-in does match and does send the request to the WAS server, but that application is currently stopped, the trace will show a 404 error coming back in the response from the server. So the plug-in sends the 404 error back to the browser.
500 Error
* If the request is matched by the plug-in and is sent to the WAS server, but the server is unresponsive or down, the plug-in will send an HTTP 500 error, which will show up as “Internal Server Error” in the browser.
* If there are multiple servers in the ServerCluster, the plug-in will try all of the servers before sending the 500 error to the browser.
Websphere (WAS) Work Load Management
Work Load Management (WLM)
This is an overview of the options available for WLM in Websphere application server v6 and some common issues and resolutions in WLM
Two types of Workload Management (WLM) in WebSphere Application Server
-Web Server Plug-In WLM
-Enterprise Java Bean (EJB) WLM
=> EJB WLM balances WLM enabled RMI/IIOP requests between clients and clusters
The load balancing occurs for the following:
* JNDI Lookups
* EJB creates
* EJB business methods
* EJB removes
=> Types of clients that support EJB WLM
* AppServers hosting client application
* WebSphere managed Application clients
* Stand alone JavaTM clients
=>WLM Routing
How it happens?
* Routing is based on weights associated with cluster members
* Round Robin routing when weights are equal
* Weights can be modified to send more requests to a particular cluster member or members
Note: If the client is on the same physical box as the cluster, the “Prefer Local” setting will ensure that all requests from the client go to the local cluster member.
=>Commonly encountered erros
* EJB requests not load balanced between cluster members
• Uneven routing
• No requests sent to a particular member
• NO_IMPLMENT errors
• No Available Target
• No Cluster Data Available
• Forward Limit Reached/Retry Limit Reached
=> Basic Troubleshooting
1. Gather ORB/WLM tracing on client where routing problem occurs (ORBRas=all:WLM*=all)
2. Find all of the three parameter getConnection() lines
3. Determine if the host/port for each similar operation are rotating between the cluster members
=> WLM trace points
* Keyword “Unexpected”
• Trace point to indicate things that should not be happening
* popServerForInvocation()
• Selected cluster member target printed during trace exit, this can be used to confirm WLM routing
* setObservedWeight()
• Used to decrement weight of cluster member during request routing. Check to ensure maximum observed weight is n-1 of the configured value for the cluster member
=> Further troubleshooting
* Check the configured Weights for each cluster member under Servers > Clusters > NAME > Cluster Members
* Check for a static routing table in the cluster config directory on the target EJB cell:/config/cells/cell_name/clusters/cluster_name/cluster_name.wsrttbl
* Check the Prefer Local setting for the cluster if the client and cluster member receiving all the requests are on the same host
=> HA Manager
* HA Manager Service required to be enabled by WLM. WLM uses information from the HA Manager Bulletin Board
* Check for DCS view exceptions or warnings in the SystemOut.log
* Check Core Group configuration
* EJB client, EJB cluster, and cluster Nodeagents should be in same core group
=> ORB Problems
* Base ORB part of SDK and layer under WLM
• Try latest SDK cumulative fixpack for your WebSphere version to rule out known defects
• Use ORB/WLM traces to determine if there is an underlying ORB exception leading to WLM problem
=> WLM Exceptions (some examples)
CORBA.NO_IMPLEMENT: No Cluster Data
* Where: Occurs on a Nodeagent
* Reson: Indicates that the process does not have WLM data for the target cluster and is unable to gather any
* Solution: Check HA Manager configuration to ensure Nodeagent is in the same core group. If HA config is correct, gather ORB/WLM trace on both client and Nodeagent
CORBA.NO_IMPLEMENT: No Available Target
* Where: Occurs on Nodeagents and clients
* Reson: WLM attempted to route a request, but based on the current cluster data, there was not a target which would be able to service that request
* Solution: Check for known APARs at your WebSphere version (most common problem fixed). Gather ORB/WLM traces on client and Nodeagent if no solution found
CORBA.NO_IMPLEMENT: Forward Limit Reached and CORBA.NO_IMPLEMENT:Retry Limit Reached
* Where: Occurs on a Nodeagent (Forward Limit) or a client (Retry Limit)
* Reson: Error thrown when 10 consecutive errors occur while trying route a request
* Solution: Check for known APARs at your WebSphere version. Gather ORB/WLM traces on client and Nodeagent to determine what underlying exception is leading to the retries
CORBA.TRANSIENT: SIGNAL_RETRY
* Where: Occurs on a client
* Reson: The ORB attempts to send a request out to a target that WLM chooses and then never receives a reply whether the request was successful or not. Usually caused by CORBA.NO_RESPONSE exception
* Solution: Gather ORB/WLM trace on the client to determine where request was sent. Next, a trace should be gathered on the target server to determine why request did not complete. The client should retry the request if this exception is caught.
This is an overview of the options available for WLM in Websphere application server v6 and some common issues and resolutions in WLM
Two types of Workload Management (WLM) in WebSphere Application Server
-Web Server Plug-In WLM
-Enterprise Java Bean (EJB) WLM
=> EJB WLM balances WLM enabled RMI/IIOP requests between clients and clusters
The load balancing occurs for the following:
* JNDI Lookups
* EJB creates
* EJB business methods
* EJB removes
=> Types of clients that support EJB WLM
* AppServers hosting client application
* WebSphere managed Application clients
* Stand alone JavaTM clients
=>WLM Routing
How it happens?
* Routing is based on weights associated with cluster members
* Round Robin routing when weights are equal
* Weights can be modified to send more requests to a particular cluster member or members
Note: If the client is on the same physical box as the cluster, the “Prefer Local” setting will ensure that all requests from the client go to the local cluster member.
=>Commonly encountered erros
* EJB requests not load balanced between cluster members
• Uneven routing
• No requests sent to a particular member
• NO_IMPLMENT errors
• No Available Target
• No Cluster Data Available
• Forward Limit Reached/Retry Limit Reached
=> Basic Troubleshooting
1. Gather ORB/WLM tracing on client where routing problem occurs (ORBRas=all:WLM*=all)
2. Find all of the three parameter getConnection() lines
3. Determine if the host/port for each similar operation are rotating between the cluster members
=> WLM trace points
* Keyword “Unexpected”
• Trace point to indicate things that should not be happening
* popServerForInvocation()
• Selected cluster member target printed during trace exit, this can be used to confirm WLM routing
* setObservedWeight()
• Used to decrement weight of cluster member during request routing. Check to ensure maximum observed weight is n-1 of the configured value for the cluster member
=> Further troubleshooting
* Check the configured Weights for each cluster member under Servers > Clusters > NAME > Cluster Members
* Check for a static routing table in the cluster config directory on the target EJB cell:
* Check the Prefer Local setting for the cluster if the client and cluster member receiving all the requests are on the same host
=> HA Manager
* HA Manager Service required to be enabled by WLM. WLM uses information from the HA Manager Bulletin Board
* Check for DCS view exceptions or warnings in the SystemOut.log
* Check Core Group configuration
* EJB client, EJB cluster, and cluster Nodeagents should be in same core group
=> ORB Problems
* Base ORB part of SDK and layer under WLM
• Try latest SDK cumulative fixpack for your WebSphere version to rule out known defects
• Use ORB/WLM traces to determine if there is an underlying ORB exception leading to WLM problem
=> WLM Exceptions (some examples)
CORBA.NO_IMPLEMENT: No Cluster Data
* Where: Occurs on a Nodeagent
* Reson: Indicates that the process does not have WLM data for the target cluster and is unable to gather any
* Solution: Check HA Manager configuration to ensure Nodeagent is in the same core group. If HA config is correct, gather ORB/WLM trace on both client and Nodeagent
CORBA.NO_IMPLEMENT: No Available Target
* Where: Occurs on Nodeagents and clients
* Reson: WLM attempted to route a request, but based on the current cluster data, there was not a target which would be able to service that request
* Solution: Check for known APARs at your WebSphere version (most common problem fixed). Gather ORB/WLM traces on client and Nodeagent if no solution found
CORBA.NO_IMPLEMENT: Forward Limit Reached and CORBA.NO_IMPLEMENT:Retry Limit Reached
* Where: Occurs on a Nodeagent (Forward Limit) or a client (Retry Limit)
* Reson: Error thrown when 10 consecutive errors occur while trying route a request
* Solution: Check for known APARs at your WebSphere version. Gather ORB/WLM traces on client and Nodeagent to determine what underlying exception is leading to the retries
CORBA.TRANSIENT: SIGNAL_RETRY
* Where: Occurs on a client
* Reson: The ORB attempts to send a request out to a target that WLM chooses and then never receives a reply whether the request was successful or not. Usually caused by CORBA.NO_RESPONSE exception
* Solution: Gather ORB/WLM trace on the client to determine where request was sent. Next, a trace should be gathered on the target server to determine why request did not complete. The client should retry the request if this exception is caught.
Subscribe to:
Posts (Atom)
