Last week I saw the following email quite rightly thanking a bunch of developers for their herculean efforts in managing against, the odds, to launch a web app on time for an industry show. It went something like this:
“We've had late nights, all nights, plans A - E, last minute AAARRRGGGHHHs, frantic calls to the server company, web servers going down on launch day, cancelled holidays, tension and early stage Stockholm Syndrome. Yet somehow we did it and are still talking to each other. The following people should stand up and take the applause they justly deserve because it has been a truly amazing effort: Laura, Mo, Sir Chris, Jason, Alistair, Andy, Jess, Victoria, Greg, Ben and Bradley1.”
...and therein lies the problem.
Java tips, observations, bugs and problems from the world of Spring, Weblogic, Oracle, MySQL and many other technologies...
Wednesday, 31 October 2012
Sunday, 28 October 2012
Investigating Deadlocks – Part 4: Fixing the Code
In the last in this short series of blogs in which I’ve been talking about analysing deadlocks, I’m going to fix my BadTransferOperation code. If you've seen the other blogs in this series, you'll know that in order to get to this point I’ve created the demo code that deadlocks, shown how to get hold of a thread dump and then analysed the thread dump, figuring out where and how a deadlock was occurring.
Labels:
Concurrency,
Deadlock,
Debug,
Java,
Multi-Threading,
MultiThreading,
Threading
Thursday, 25 October 2012
Investigating Deadlocks – Part 3: Analysing the Thread Dump
In my previous two blogs in this series, part 1 and part 2, I’ve demonstrated how to create a piece of bad code that deadlocks and then used this code to show three ways of taking a thread dump. In this blog I’m going to analyze the thread dump to figure out what when wrong.
Labels:
Concurrency,
Deadlock,
Debug,
Java,
Multi-Threading,
MultiThreading,
Threading
Tuesday, 23 October 2012
Investigating Deadlocks – Part 2: Obtaining the Thread Dump
One of the most important requirements when investigating deadlocks is actually having a deadlock to investigate. In my last blog I wrote some code called DeadlockDemo that used a bunch of threads to transfer random amounts between a list of bank accounts before grinding to a halt in a deadlock.
This blog runs that code to demonstrates a few ways of obtaining a thread dump.
This blog runs that code to demonstrates a few ways of obtaining a thread dump.
Labels:
Concurrency,
Deadlock,
Debug,
Java,
Multi-Threading,
MultiThreading,
Threading
Thursday, 18 October 2012
Investigating Deadlocks – Part 1: Creating a Deadlock
I’m sure we’ve all been there: it’s late, you’re hungry, your server has hung or your application’s running at snail’s pace, and there’s someone breathing down your neck wanting you to fix the problem before you go. One of the possible causes of your application hanging unexpectedly is a threading issue known as a Deadlock.
Without going into too much detail, threads can be in one of a number of states as shown by the UML state diagram below...
Without going into too much detail, threads can be in one of a number of states as shown by the UML state diagram below...
Labels:
Concurrency,
Deadlock,
Debug,
Java,
Multi-Threading,
MultiThreading.,
Threading
Monday, 8 October 2012
Apple Mac Time Machine Runs Very Slowly
Not a lot of people know this, but I write many of my blogs in The Wolverhampton Art Gallery’s cafe: the food’s really good and, for a provincial art gallery, there are some very fine painting to be seen producing an atmosphere I find conducive to writing.
Labels:
Apple,
Mac,
MacOS,
Performance,
Spotlight,
Time Machine
Subscribe to:
Posts (Atom)