Thursday, March 26, 2009

Saving a file being viewed in less

Sometimes I have a long sequence of command line pipes that end in less command. For e.g.
cvs log main.c | egrep "^revision " | less
So what is the best way to save the contents that are being viewed in less? You cannot view those contents by typing the letter "v". If you do so you will get an error message saying "Cannot edit standard input (press RETURN)".

The solution is simple. First type "g" to go to the beginning of the file. Then type "|". Then you will be prompted for the "mark:" and enter "$" (which denotes the end of file). Then you can enter a command for which the entire contents of less will be piped. For e.g. I will give the following:
cat > /tmp/savefile.txt
Thats it! You have saved the contents to the file /tmp/savefile.txt. Now you have a problem. Since you have moved to the beginning of the contents, you might want to go back to the same place where you were before saving the contents. Just type "''" i.e. single quote twice. You should be back at where you were before you started saving the file.

Hope this little trick saves a lot of time for you! If yes, please drop me a word :-)

Monday, March 23, 2009

So you think you understand misfireThreshold?

One of the most critical and least documented features of Quartz is the concept of misfiring and how misfiring is handled. If a trigger was supposed to carry out a job a certain time, and for some reason it was not carried out at that time, it is a misfired trigger. But not any trigger could be treated as a misfired trigger. For e.g. if a trigger is long due for 2 hours from its actual firing time, does it make sense to treat that as a misfired trigger? To make that decision Quartz scheduler relies upon a configurable parameter called misfireThreshold. It is specified in milliseconds. Whenever a trigger is due for misfireThreshold or lesser amount of time, it will be treated as a misfired trigger and triggered depending on the misfire policy specified in the job detail.

For e.g. on a certain situation you might want a misfired trigger to be fired immediately, on a certain other situation you might decide its okay to reschdule the same trigger to the next firing time. For SimpleTrigger, there are five policies available and all of them are documented as a part of the API here. They are pretty much self explonatory.

It is critical to understand the default value of misfireThreshold is 30 seconds. As an example, consider you have a trigger that gets fired once in every 1 second to carry out a job that cannot be concurrently executed. The job usually takes less than a second to complete, but on a certain instance it takes around 20 seconds to complete. As soon as that job is complete, you will see that there are 19 times the same job was fired immediately! This is because, all the 19 times when the trigger must have fired qualify as misfired triggers by the default value of misfireThreshold.

One of the bad things that could happen when the above mentioned scenario happens is there are a large number of triggers that need to be carried out within a short interval of time. This might not be a desired thing, also it introduces starvation at times. I have observed that the misfired trigger gets executed repeatedly blocking the execution of other triggers!

My suggestion is to keep the misfireThreshold to be half of the repeat interval. Of course, it depends on your application too. But in general, this might be good enough. Remember that misfireThreshold is common acros all the triggers, where as the repeatInterval is for each trigger. So if you have various triggers with differing repeat intervals, decide what is the optimum value for your case.

One thing I am repeatedly assured about using Open Source Software is never think that the default configuration parameters are fit for most of the cases. Some of my situations have required tuning using often least documented or least understood parameters!

Wednesday, March 11, 2009

More comments on JDBC batch update return codes

This is a quick follow up to my earlier post on JDBC batch update return codes. There are two constants that you can conveniently make use of to check the error codes available in java.sql.Statement:
SUCCESS_NO_INFO - The UPDATE or INSERT corresponding to this input values has succeeded but the number of rows that it affected is unknown.
EXECUTE_FAILED - The UPDATE or INSERT corresponding to this input values has failed.

Wednesday, March 04, 2009

Eclipse CVS error

Today while I was trying to synchronize my code with CVS repository and I got the following error:
Problems reported while synchronizing CVS Workspace. 0 of 1 resources were synchronized.
An error occurred synchronizing /abcd: I/O exception occurred: channel is broken
I/O exception occurred: channel is broken channel is broken
I was scratching my head for sometime and searched Internet for an answer, but none seemed to be appropriate for my case. Then when I tried to do the check out from command line using plink, I got a message from my CVS server stating that my password had expired and I needed to change my password. So I changed my password and everything started working fine.

If you get the error message above, one possible and easy to check root causes is your password expiry.

Monday, March 02, 2009

Understanding return codes of JDBC batchUpdate

Recently I had to make use of the JdbcTemplate.batchUpdate() facility in Spring. I was connecting to the Oracle database using Oracle JDBC driver. As per the documentation, the batchUpdate() function is supposted to return an integer array. Each element in the array contains the number of rows affected the respective INSERT/UPDATE/DELETE query in the batch. But during my testing I found that, I was always getting all the elements to be -2.

Initially I was thinking it was a bug in the driver code. Then when I was referring to the JDBC Programmers Guide, I figured the following:
For a prepared statement batch, it is not possible to know the number of rows affected in the database by each individual statement in the batch. Therefore, all array elements have a value of -2. According to the JDBC 2.0 specification, a value of -2 indicates that the operation was successful but the number of rows affected is unknown.

There are more examples and explonation of error codes in the same page. Especially pay more attention to the case when one of the statements throw an exception:
For example, if there were 20 operations in the batch, the first 13 succeeded, and the 14th generated an exception, then the update counts array will have 13 elements, containing actual update counts of the successful operations.

Hope this helps you are seeing the mysterious -2 as return code!