Once upon a time there was a painter who had just completed his course. He took 3 days and painted beautiful scenery. He wanted people's opinion about his caliber and painting skills.
He put his creation at a busy street-crossing. And just down below aboard which read -"I have painted this piece. Since I'm new to this profession I might have committed some mistakes in my strokes etc. Please put a cross wherever you see a mistake."
While he came back in the evening to collect his painting he was completely shattered to see that whole canvass was filled with Xs (crosses) and some people had even written their comments on the painting.
Disheartened and broken completely he ran to his master's place and burst into tears.
This young artist was breathing heavily and master heard him saying"I'm useless and if this is what I have learnt to paint I'm not worth becoming a painter. People have rejected me completely. I feel like dying"
Master smiled and suggested "My Son, I will prove that you are a great artist and have learnt a flawless painting. Do as I say without questioning it. It WILL work."
Young artist reluctantly agreed and two days later early morning he presented a replica of his earlier painting to his master. Master took that gracefully and smiled.
"Come with me." master said.
They reached the same street-square early morning and displayed the same painting exactly at the same place. Now master took out another board which read -"Gentlemen, I have painted this piece. Since I'm new to this profession I might have committed some mistakes in my strokes etc. I have put a box with colors and brushes just below. Please do a favor. If you see a mistake, kindly pick up the brush and correct it."
Master and disciple walked back home.
They both visited the place same evening. Young painter was surprised to see that actually there was not a single correction done so far. Next day again they visited and found painting remained untouched. They say the painting was kept there for a month for no correction came in!
Moral of the story:
It is easier to criticize, but DIFFICULT TO IMPROVE!
So don't get carried away or judge yourself by someone else’s criticism and feel depressed...
JUDGE YOURSELF! YOU ARE YOUR BEST JUDGE!!!
Originally from - shrinivas mujumdar.
Showing posts with label Misc. Show all posts
Showing posts with label Misc. Show all posts
Thursday, February 3, 2011
Tuesday, January 5, 2010
How to edit xml, java, html code in blogs
I was new to blogging and was trying to publish xml code in my blog text. When I previewed my blog....it was not as expected...no xml tags were there and only the values for xml tags are present. I googled for inserting xml text inside blog text and found one helpful and easy solution.
Hope this will help to needfuls
http://www.anshuldudeja.com/2009/07/how-to-post-xmlhtmljava-script-and-such.html
one more thing can help u
http://www.simplebits.com/cgi-bin/simplecode.pl
Hope this will help to needfuls
http://www.anshuldudeja.com/2009/07/how-to-post-xmlhtmljava-script-and-such.html
one more thing can help u
http://www.simplebits.com/cgi-bin/simplecode.pl
Wednesday, December 30, 2009
ant build - xml:base attribute in ejb-jar files
Building the application using ant was causing the default xml:base attribute in 'session', 'entity' tags of the ejb-jar.xml files.
This attribute was causing the problem with application deployment. This attribute might be useful but in my case I wanted this attribute not to be there in xml files.
After googling the web I didn't found any solution to remove this attribute.
I tried it 3-4 times and once did a clean build and guess what I found the solution.
Doing a clan build remived those attributes in 'session', 'entity' tags of the ejb-jar.xml files.
This attribute was causing the problem with application deployment. This attribute might be useful but in my case I wanted this attribute not to be there in xml files.
After googling the web I didn't found any solution to remove this attribute.
I tried it 3-4 times and once did a clean build and guess what I found the solution.
Doing a clan build remived those attributes in 'session', 'entity' tags of the ejb-jar.xml files.
Before J2EE application performance optimization
Before really starting to optimize the performance of J2EE application, everyone tries to identify the areas which is causing the performance reduction.
Here is what I feel one should look at for identifying the problem areas
There will be all the way four sources of performance problems in J2EE applications:
* The application code (Back-end or GUI)
* The environment upon which the application is running (application server, JVM, pperating system, network, etc.)
* External dependencies (database, legacy system, Web service, native server, etc.)
* Excessive load
By identifying these four facets of performance problems, we can better formulate a plan to analyze the root-cause(s) of performance problems,
and then develop a resolution plan.
To summarize these four performance facets:
1. The problem can be in the application itself :
There can problem with application code. I am giving some examples but these are not all, there can be more.
excessive object creations, inefficient loops and iterations, more database stuff in code, GUI code problems....a big list.
2. The configuration of the environment:
The environment in which the application is running. This basically covers the application server configuration.
Considering four major parameters are well configured in application server, you are 80% done of the performance optimization.
Heap configuration - For garbage collection stuff.
Thread pools - If you do not have a thread to serve an incoming request, the tuning won't matter, because the request will be queued up waiting to be processed.
Database connection pools - If you do not have enough database connections in your pools, requests will process as far as they can...
and then wait for a database connection, introducing a new bottleneck.
Entity Bean cache - If cache is too small, the overhead to maintain the cache will overpower the benefit you receive by using it;
and if it is too large, you are unnecessarily using too much heap!
3.Something upon which the application depends.
This area covers the other systems like database, web service, legacy system, etc. Note:A database configuaration optimization can improve the application performance dramatically.
4. Excessive load : If there is excessive load on the application than expected, for which it was designed.
If it is none of the above, then the environment has reached its capacity and it's time to add hardware.
Note that throwing hardware at a problem is the last choice, not the first!
Here is what I feel one should look at for identifying the problem areas
There will be all the way four sources of performance problems in J2EE applications:
* The application code (Back-end or GUI)
* The environment upon which the application is running (application server, JVM, pperating system, network, etc.)
* External dependencies (database, legacy system, Web service, native server, etc.)
* Excessive load
By identifying these four facets of performance problems, we can better formulate a plan to analyze the root-cause(s) of performance problems,
and then develop a resolution plan.
To summarize these four performance facets:
1. The problem can be in the application itself :
There can problem with application code. I am giving some examples but these are not all, there can be more.
excessive object creations, inefficient loops and iterations, more database stuff in code, GUI code problems....a big list.
2. The configuration of the environment:
The environment in which the application is running. This basically covers the application server configuration.
Considering four major parameters are well configured in application server, you are 80% done of the performance optimization.
Heap configuration - For garbage collection stuff.
Thread pools - If you do not have a thread to serve an incoming request, the tuning won't matter, because the request will be queued up waiting to be processed.
Database connection pools - If you do not have enough database connections in your pools, requests will process as far as they can...
and then wait for a database connection, introducing a new bottleneck.
Entity Bean cache - If cache is too small, the overhead to maintain the cache will overpower the benefit you receive by using it;
and if it is too large, you are unnecessarily using too much heap!
3.Something upon which the application depends.
This area covers the other systems like database, web service, legacy system, etc. Note:A database configuaration optimization can improve the application performance dramatically.
4. Excessive load : If there is excessive load on the application than expected, for which it was designed.
If it is none of the above, then the environment has reached its capacity and it's time to add hardware.
Note that throwing hardware at a problem is the last choice, not the first!
How to use MINUS operator in MsSql as opposed to Oracle
How to get result of one sql and subtract the result of another sql dynamically in MsSql server. If you are aware of the MINUS keyword used in oracle.
like
select emp_id from employee where dept='MANUFACTURING'
minus
select emp_id from employee where emp_ctgry='SUPERVISOR'
This will list out the employees which are not under SUPERVISOR category.
How to do similar job in MsSql, where you can not use MINUS as it is not MsSql specific ?
The answer is you will need to use 'EXCEPT' keyword, which is equivalent to MINUS in Oracle.
I'm not very sure but as per my knowledge MsSql 6.5 does not support MINUS operator.
like
select emp_id from employee where dept='MANUFACTURING'
minus
select emp_id from employee where emp_ctgry='SUPERVISOR'
This will list out the employees which are not under SUPERVISOR category.
How to do similar job in MsSql, where you can not use MINUS as it is not MsSql specific ?
The answer is you will need to use 'EXCEPT' keyword, which is equivalent to MINUS in Oracle.
I'm not very sure but as per my knowledge MsSql 6.5 does not support MINUS operator.
Friday, November 13, 2009
checkout source code from CVS repository using date
The application is in production and there is no tag on production version source code in CVS.
We came across the same situation where we required to get the source code which has no tag in CVS.
Thank god we had the date and branch name on which production application was built.
The job was to get the source code from CVS using this build date.
In above scenario, there are various approaches to get this version but I would suggest the following one
There is a command which can do the job for you
cvs checkout -D$DATE -r$TAG $MODULE
To run this command you might need to set the property for CVSROOT, this will address the cvs repository loaction.
In linux you can set this in bashrc file as follows
export CVSROOT=$user@$cvs_server_repository_location
e.g. export CVSROOT=ganesh@100.200.300.400:/my/cvs/repository
example : cvs checkout -D3/31/92 10:00:07 PST -rMyBranchName MyModuleName
After setting the property you will be able to checkout from cvs
Following are the few of the valid date formats
1 month ago
2 hours ago
400000 seconds ago
last year
last Monday
yesterday
a fortnight ago
3/31/92 10:00:07 PST
January 23, 1987 10:05pm
22:00 GMT
All the best.... !!!!!!
We came across the same situation where we required to get the source code which has no tag in CVS.
Thank god we had the date and branch name on which production application was built.
The job was to get the source code from CVS using this build date.
In above scenario, there are various approaches to get this version but I would suggest the following one
There is a command which can do the job for you
cvs checkout -D$DATE -r$TAG $MODULE
To run this command you might need to set the property for CVSROOT, this will address the cvs repository loaction.
In linux you can set this in bashrc file as follows
export CVSROOT=$user@$cvs_server_repository_location
e.g. export CVSROOT=ganesh@100.200.300.400:/my/cvs/repository
example : cvs checkout -D3/31/92 10:00:07 PST -rMyBranchName MyModuleName
After setting the property you will be able to checkout from cvs
Following are the few of the valid date formats
1 month ago
2 hours ago
400000 seconds ago
last year
last Monday
yesterday
a fortnight ago
3/31/92 10:00:07 PST
January 23, 1987 10:05pm
22:00 GMT
All the best.... !!!!!!
Friday, August 28, 2009
Unicode Character info
If you want an information regarding the unicode characters, what a particular unicode character stands for, the following link is one of the best links I would suggest to prefer.
http://www.fileformat.info/info/unicode/char/0019/index.htm
Just put your character code in above url at the place of '0019' and you will get all the info related to the character.
http://www.fileformat.info/info/unicode/char/0019/index.htm
Just put your character code in above url at the place of '0019' and you will get all the info related to the character.
Friday, July 10, 2009
SWIFT message types
SWIFT message types
SWIFT messages consist of five blocks of data including three headers, message content, and a trailer. Message types are crucial to identifying content.
All SWIFT messages include the literal "MT" (Message Type). This is followed by a 3-digit number that denotes the message type, category, and group. Consider the following example, which is an order to buy or sell via a third party:
- MT502
- The first digit (5) represents the category. A category denotes messages that relate to particular financial instruments or services such as Precious Metals, Syndications, or Travelers Checks. The category denoted by 5 is Securities Markets.
The second digit (0) represents a group of related parts in a transaction life cycle. The group indicated by 0 is a Financial Institution Transfer.
The third digit (2) is the type that denotes the specific message. There are several hundred message types across the categories. The type represented by 2 is a Third-Party Transfer.
Each message is assigned unique identifiers.
A 4-digit session number is assigned each time the user logs in.
Each message is then assigned a 6-digit sequence number.
These are then combined to form an ISN (Input Sequence Number) from the user's computer to SWIFT or an OSN (Output Sequence Number) from SWIFT to the user's computer. It is important to remember that terminology is always from the perspective of SWIFT and not the user.
The Logical Terminal Address (12 character BIC), Day, Session and Sequence numbers combine to form the MIR (Message Input Reference) and MOR (Message Output Reference), respectively.
Thursday, July 9, 2009
java.rmi.NoSuchObjectException: Bean has been deleted
I was facing 'java.rmi.NoSuchObjectException: Bean has been deleted' for the stateful bean instance.
While reading about the error, I came across very useful information, which I would like to share with.
This error can specifically occur in one of the following two scenarios
1. Calling a method on the bean which is deleted from cache and disk.
2. Calling EJBHome.remove() on bean, which is deployed on cluster.
#1. Default idle time out of a session bean from a container cache is 600 seconds. After 600 seconds if the max-bean-in-cache size is reached, then the corresponding bean is removed from the cache and passivated to hard disk. When client tries to access this passivated bean after it has been removed from hard disk from container, server will throw the above error.
Possible Solution : In weblogic-ejb-jar.xml, we can configure the idle-timeout-seconds (more than 600). Bean will be passivated to hard disk from cache after idle timeout seconds are reached.
Also configuring session-timeout-seconds, which specifies how long the EJB container waits before removing an idle stateful session bean from disk. While passivated, EJBs are not in memory and are not immediately available for client requests, as they are when in the cache.
#2. Bea suggest to use EJBObject.remove(), instead of EJBHome.remove(), to remove a stateful session bean that is deployed on cluster.
No stateful session EJB instances exist in WebLogic Server at startup.
When I read upon more, I found, the rules that govern the passivation of stateful session beans vary, based on the value of the beans cache-type element,
which can be:
1. LRU - Least Recently Used (Eager Passivation)
2. NRU - Not Recently Used (Lazy Passivation)
The default value of the cache type is NRU. With this, the minimum cache size is 8.
If we configure max-bean-in-cache as less than 3, the weblogic will use max-bean-in-cache value as 8.
This is the default strategy and also an eager remove strategy in which the container decides to remove the bean instead of passivating after idle-timeout-seconds.
While reading about the error, I came across very useful information, which I would like to share with.
This error can specifically occur in one of the following two scenarios
1. Calling a method on the bean which is deleted from cache and disk.
2. Calling EJBHome.remove() on bean, which is deployed on cluster.
#1. Default idle time out of a session bean from a container cache is 600 seconds. After 600 seconds if the max-bean-in-cache size is reached, then the corresponding bean is removed from the cache and passivated to hard disk. When client tries to access this passivated bean after it has been removed from hard disk from container, server will throw the above error.
Possible Solution : In weblogic-ejb-jar.xml, we can configure the idle-timeout-seconds (more than 600). Bean will be passivated to hard disk from cache after idle timeout seconds are reached.
Also configuring session-timeout-seconds, which specifies how long the EJB container waits before removing an idle stateful session bean from disk. While passivated, EJBs are not in memory and are not immediately available for client requests, as they are when in the cache.
#2. Bea suggest to use EJBObject.remove(), instead of EJBHome.remove(), to remove a stateful session bean that is deployed on cluster.
No stateful session EJB instances exist in WebLogic Server at startup.
When I read upon more, I found, the rules that govern the passivation of stateful session beans vary, based on the value of the beans cache-type element,
which can be:
1. LRU - Least Recently Used (Eager Passivation)
2. NRU - Not Recently Used (Lazy Passivation)
The default value of the cache type is NRU. With this, the minimum cache size is 8.
If we configure max-bean-in-cache as less than 3, the weblogic will use max-bean-in-cache value as 8.
This is the default strategy and also an eager remove strategy in which the container decides to remove the bean instead of passivating after idle-timeout-seconds.
Monday, April 20, 2009
Choose form validation style carefully
In web applications, validation of user input can be done with two different tools :
* scripting code executed by the browser (javascript, for example)
* regular java code executed by the server, as part of the web application
Server validation :
* cannot be disabled by a change in browser preferences
* executes only after the SUBMIT button is pressed
* validates all fields of the form as one unit
* if an error is detected, a new web page is displayed, with an appropriate error message
Browser validation :
* can be disabled by a change in browser preferences
* can be initiated in two ways : after the SUBMIT button is pressed, or after an input field has changed
* if executing after SUBMIT is pressed, the form's data is POST-ed to the server only if validation is successful
* if an error is detected, a pop-up dialog box is displayed
Another important distinction between the two styles deals not with their behaviour, but with their testability. Validation code on the server can always be tested economically using tools such as JUnit. During the entire life of an application, such tests can be quickly repeated using automated means, helping to identify possible errors caused by code changes. Although tools such as HttpUnit can test javascript behaviour in web applications, such tests do not seem to be as simple to implement as JUnit tests on a Model Object.
Browser validation seems most useful for :
* low bandwidth environments
* forms with a large number of fields, each validated as it is input
If using scripting, should validation be done after SUBMIT is pressed, or as each field is changed?
If there are no dependencies between fields, there is not much difference between the two styles. However, if there are dependencies between fields, which is quite common, then the validate-after-SUBMIT style is likely to be simpler to implement.
Many prefer to treat server validation as mandatory and browser validation as optional, either as a performance optimisation or as the preferred user experience. If both are implemented, then this will usually represent significant code repetition.
* scripting code executed by the browser (javascript, for example)
* regular java code executed by the server, as part of the web application
Server validation :
* cannot be disabled by a change in browser preferences
* executes only after the SUBMIT button is pressed
* validates all fields of the form as one unit
* if an error is detected, a new web page is displayed, with an appropriate error message
Browser validation :
* can be disabled by a change in browser preferences
* can be initiated in two ways : after the SUBMIT button is pressed, or after an input field has changed
* if executing after SUBMIT is pressed, the form's data is POST-ed to the server only if validation is successful
* if an error is detected, a pop-up dialog box is displayed
Another important distinction between the two styles deals not with their behaviour, but with their testability. Validation code on the server can always be tested economically using tools such as JUnit. During the entire life of an application, such tests can be quickly repeated using automated means, helping to identify possible errors caused by code changes. Although tools such as HttpUnit can test javascript behaviour in web applications, such tests do not seem to be as simple to implement as JUnit tests on a Model Object.
Browser validation seems most useful for :
* low bandwidth environments
* forms with a large number of fields, each validated as it is input
If using scripting, should validation be done after SUBMIT is pressed, or as each field is changed?
If there are no dependencies between fields, there is not much difference between the two styles. However, if there are dependencies between fields, which is quite common, then the validate-after-SUBMIT style is likely to be simpler to implement.
Many prefer to treat server validation as mandatory and browser validation as optional, either as a performance optimisation or as the preferred user experience. If both are implemented, then this will usually represent significant code repetition.
Thursday, March 19, 2009
Basics of Cluster
What Is a WebLogic Server Cluster?
A WebLogic Server cluster consists of multiple WebLogic Server server instances running simultaneously and working together to provide increased scalability and reliability. A cluster appears to clients to be a single WebLogic Server instance. The server instances that constitute a cluster can run on the same machine, or be located on different machines.
You can increase a cluster's capacity by adding additional server instances to the cluster on an existing machine, or you can add machines to the cluster to host the incremental server instances. Each server instance in a cluster must run the same version of WebLogic Server.
A cluster is part of a particular WebLogic Server domain.
A domain can include multiple clusters. Clustered WebLogic Server instances behave similarly to non-clustered instances, except that they provide failover and load balancing.
What Are the Benefits of Clustering?
A WebLogic Server cluster provides these benefits:
* Scalability
The capacity of an application deployed on a WebLogic Server cluster can be increased dynamically to meet demand. You can add server instances to a cluster without interruption of service—the application continues to run without impact to clients and end users.
* High-Availability
In a WebLogic Server cluster, application processing can continue when a server instance fails. You "cluster" application components by deploying them on multiple server instances in the cluster—so, if a server instance on which a component is running fails, another server instance on which that component is deployed can continue application processing.
What Are the Key Capabilities of a Cluster?
# Application Failover
Simply put, failover means that when an application component (typically referred to as an "object" in the following sections) doing a particular "job"—some set of processing tasks—becomes unavailable for any reason, a copy of the failed object finishes the job.
WebLogic Server uses standards-based communication techniques and facilities—multicast, IP sockets, and the Java Naming and Directory Interface (JNDI)—to share and maintain information about the availability of objects in a cluster.
# Server Migration
WebLogic Server supports automatic and manual migration of a clustered server instance from one machine to another.A Managed Server configured for automatic migration will be automatically migrated to another machine in the even of failure.
# Load Balancing
Load balancing is the even distribution of jobs and associated communications across the computing and networking resources in your environment. For load balancing to occur:
* There must be multiple copies of an object that can do a particular job.
* Information about the location and operational status of all objects must be available.
WebLogic Server allows objects to be clustered—deployed on multiple server instances—so that there are alternative objects to do the same job. WebLogic Server shares and maintains the availability and location of deployed objects using multicast, IP sockets, and JNDI.
A WebLogic Server cluster consists of multiple WebLogic Server server instances running simultaneously and working together to provide increased scalability and reliability. A cluster appears to clients to be a single WebLogic Server instance. The server instances that constitute a cluster can run on the same machine, or be located on different machines.
You can increase a cluster's capacity by adding additional server instances to the cluster on an existing machine, or you can add machines to the cluster to host the incremental server instances. Each server instance in a cluster must run the same version of WebLogic Server.
A cluster is part of a particular WebLogic Server domain.
A domain can include multiple clusters. Clustered WebLogic Server instances behave similarly to non-clustered instances, except that they provide failover and load balancing.
What Are the Benefits of Clustering?
A WebLogic Server cluster provides these benefits:
* Scalability
The capacity of an application deployed on a WebLogic Server cluster can be increased dynamically to meet demand. You can add server instances to a cluster without interruption of service—the application continues to run without impact to clients and end users.
* High-Availability
In a WebLogic Server cluster, application processing can continue when a server instance fails. You "cluster" application components by deploying them on multiple server instances in the cluster—so, if a server instance on which a component is running fails, another server instance on which that component is deployed can continue application processing.
What Are the Key Capabilities of a Cluster?
# Application Failover
Simply put, failover means that when an application component (typically referred to as an "object" in the following sections) doing a particular "job"—some set of processing tasks—becomes unavailable for any reason, a copy of the failed object finishes the job.
WebLogic Server uses standards-based communication techniques and facilities—multicast, IP sockets, and the Java Naming and Directory Interface (JNDI)—to share and maintain information about the availability of objects in a cluster.
# Server Migration
WebLogic Server supports automatic and manual migration of a clustered server instance from one machine to another.A Managed Server configured for automatic migration will be automatically migrated to another machine in the even of failure.
# Load Balancing
Load balancing is the even distribution of jobs and associated communications across the computing and networking resources in your environment. For load balancing to occur:
* There must be multiple copies of an object that can do a particular job.
* Information about the location and operational status of all objects must be available.
WebLogic Server allows objects to be clustered—deployed on multiple server instances—so that there are alternative objects to do the same job. WebLogic Server shares and maintains the availability and location of deployed objects using multicast, IP sockets, and JNDI.
Subscribe to:
Posts (Atom)