Monday, May 14, 2018
Thursday, May 13, 2010
Xen DomU hanging at "Checking for hardware changes"? Check your xenconsoled in your Dom0.
Dear self,
This is the second time this has happened to me, so I'm writing to you, my future self, a quick note so you don't have to relearn this a second time.
If when restarting a DomU, the DomU hangs at "Checking for hardware changes", check on the Dom0 to see if your xenconsoled has died. If so, restart it (ie. /usr/sbin/xenconsoled) and it should immediately fix the hanging DomUs.
This guy has a blog post with same issue, but I don't think he ever figured it out because he took a scorched-earth route to fix the problem. However, it does have a nice screen shot of what the hung DomU looks like.
Yours truely,
yourself
This is the second time this has happened to me, so I'm writing to you, my future self, a quick note so you don't have to relearn this a second time.
If when restarting a DomU, the DomU hangs at "Checking for hardware changes", check on the Dom0 to see if your xenconsoled has died. If so, restart it (ie. /usr/sbin/xenconsoled) and it should immediately fix the hanging DomUs.
This guy has a blog post with same issue, but I don't think he ever figured it out because he took a scorched-earth route to fix the problem. However, it does have a nice screen shot of what the hung DomU looks like.
Yours truely,
yourself
Saturday, February 27, 2010
Monday, February 01, 2010
Stupidity, brought to you by the letter L
I grabbed some time formatting code from an older project of mine to use in my current project.
However, I noticed that the constants defined at the top of the class had some weird values. The constant, number of milliseconds per whatever, was ending in a 1 instead of a 0. My first thought was that a co-worker had mangled my source to fix some stupid off-by-one time issue they were having, incidentally breaking everything else that relied on that constant.
While 600 to 601 is a plausible change, 60 milliseconds per minute to 600 milliseconds per minute should have set off alarm bells in my head.
I spent several minutes grepping through the svn repository trying to find the lazy rat-bastard that had messed with my code, only to find that it wasn't a '601' but a '60l' (60L). The L is there to force the value into a long integer type.
Lesson learned? Use uppercase L.
Monday, December 21, 2009
Funny phishing / spam email I got
Notice the "with FBI Seal linking to FBI Home" and the "$300.00 (Five Hundred-US Dollars)"
Spam / phishing emails are a dime a dozen, but this one was so funny I had to post it.
Spam / phishing emails are a dime a dozen, but this one was so funny I had to post it.
Washington Field Office Banner with FBI Seal linking to FBI Home
Anti-Terrorist and International Fraud Division.
Federal Bureau Of Investigation.
Seattle, Washington.
Telephone Number : (206) 973-2572
ATTN: BENEFICIARY
This is to Officially inform you that it has come to our notice and we have thoroughly completed an Investigation with the help of our Intelligence Monitoring Network System that you legally won the sum of $800,000.00 US Dollars from a Lottery Company outside the United States of America. During our investigation we discovered that your e-mail won the money from an Online Balloting System and we have authorized this winning to be paid to you via a Certified Cashier's Check.
Normally, it will take up to 10 business days for an International Check to be cashed by your local bank. We have successfully notified this company on your behalf that funds are to be drawn from a registered bank within the United States Of America so as to enable you cash the check instantly without any delay, henceforth the stated amount of $800,000.00 US Dollars has been deposited with Bank Of America.
We have completed this investigation and you are hereby approved to receive the winning prize as we have verified the entire transaction to be Safe and 100% risk free, due to the fact that the funds have been deposited at Bank Of America you will be required to settle the following bills directly to the Lottery Agent in-charge of this transaction whom is located in Lagos, Nigeria. According to our discoveries, you were required to pay for the following -
(1) Deposit Fee's ( Fee's paid by the company for the deposit into an American Bank which is - Bank Of America )
(2) Cashier's Check Conversion Fee ( Fee for converting the Wire Transfer payment into a Certified Cashier's Check )
(3) Shipping Fee's ( This is the charge for shipping the Cashier's Check to your home address and this fee includes Insurance )
The total amount for everything is $300.00 (Five Hundred-US Dollars). We have tried our possible best to indicate that this $300.00 should be deducted from your winning prize but we found out that the funds have already been deposited at Bank Of America and cannot be accessed by anyone apart from you the winner, therefore you will be required to pay the required fee's to the Agent in-charge of this transaction via Western Union Money Transfer Or Money Gram.
In order to proceed with this transaction, you will be required to contact the agent in-charge ( BENSON EDWARD) via e-mail. Kindly look below to find appropriate contact information:
CONTACT AGENT NAME: MR. BENSON EDWARD
E-MAIL ADDRESS: bensonedward200@gala.net
Telephone Number : +234-813-822-3603
You will be required to e-mail him with the following information:
FULL NAME:
ADDRESS:
CITY:
STATE:
ZIP CODE:
AGE/SEX:
DIRECT CONTACT NUMBER:
You will also be required to request Western Union details on how to send the required $300.00 in order to immediately ship your prize of $800,000.00 US Dollars via Certified Cashier's Check drawn from Bank Of America, also include the following transaction code in order for him to immediately identify this transaction : EA2948-910.
This letter will serve as proof that the Federal Bureau Of Investigation is authorizing you to pay the required $300.00 ONLY to Mr. Benson Edward via information in which he shall send to you, if you do not receive your winning prize of $800,000.00 US Dollars we shall be held responsible for the loss and this shall invite a penalty of $3,000 which will be made PAYABLE ONLY to you (The Winner).
Please find below an authorized signature which has been signed by the FBI Director- Robert Mueller, also below is the FBI NSB (National Security Branch) seal.
FBI Director
Robert Mueller.
NSB Seal
Authorized Signature
NSB SEAL ABOVE
NOTE: In order to ensure your check gets delivered to you ASAP, you are advised to immediately contact Mr. BENSON EDWARD via contact information provided above and make the required payment of $300.00 to information in which he shall provide to you.
Wednesday, June 24, 2009
Don't use Integer keys with WeakHashMap
WeakHashMap relies on the key of an entry being garbage collected (due to being weakly referenced) so that the entire Map.Entry can be discarded.
However, if you use Integer as your map key, you can get suprising results when combined with autoboxing, due to a hidden cache of j.l.Integer objects embedded in java.lang.Integer itself.
This cache has been discussed in several other places (ie. http://www.owasp.org/index.php/Java_gotchas), particularly in respect to testing equality.
However, this cache of Integers from -128...127 will also mess with your WeakHashMap, pinning any elements in that range in memory, never to be released.
Here is a quick and dirty test demonstrating this issue:
public void testWeakHashMapWithIntKeys()
{
WeakHashMap<integer, stringbuffer> map = new WeakHashMap<integer, stringbuffer>();
map.put( 1, new StringBuffer("Test 1") );
map.put( 2, new StringBuffer("Test 2") );
map.put( 3, new StringBuffer("Test 3") );
map.put( 126, new StringBuffer("Test 126") );
map.put( 127, new StringBuffer("Test 127") );
map.put( 128, new StringBuffer("Test 128") );
System.out.println(map);
System.gc();
System.out.println(map);
}
You should get something like this:
{128=Test 128, 126=Test 126, 127=Test 127, 3=Test 3, 2=Test 2, 1=Test 1}
{126=Test 126, 127=Test 127, 3=Test 3, 2=Test 2, 1=Test 1}
Where the second line shows that all elements less than 128 have been retained.
This also applies to the other wrapper classes, java.lang.Byte, java.lang.Short, java.lang.Long, etc.
You can avoid this problem by not using autoboxing, and always invoking the new operator to create your keys. However, this seems to me to be error-prone. A more fool-proof strategy would be to wrap your Integer (or even a int!) in a custom class to avoid all this froo-fra.
Update: my google-foo found an example in "Pro Java Programming" (by Brett Spell), of how to not use WeakHashMap. His examples work by accident because the values he uses for the key are larger than 127.
Friday, May 08, 2009
Subscribe to:
Posts (Atom)