I have a couple of status meetings that occur at the that same time every week. I also have monthly status reports that need to be written at the end of the month. I am expected to update a daily “shift log” even though I do not work a shift. Even with all this reporting, all the meetings that I am required to attend, it seems nothing gets communicated.
At one of these weekly meetings, someone from one of our datacenters was describing a networking project, a project that seemed to have been in the works for sometime. This project was going to effect my servers and I was told that I have 2 days to prep for that change. I was also told that it would not effect our servers, but I knew better.
The time came for the change and like I expected it crashed our server. When I recovered the boxes, they could no longer communicate over multicast. That change that would not effect us, required us to reengineer a solution on our end.
Next time guys, give us more than a 2 day heads up and lets get some communication to make sure your changes will not screw us over.
Today was one of those days where things came from several directions. One of those things that carried over from yesterday was having our XMPP messaging server launch a chat window from a link on a page. I have been searching for some solutions, and none seem to be elegant. Most are like this from Ralph Meijer, it is a solution but requires a modification on each browser, not practical at our current client.
So, for now, it seems our only solution is to work with the web team to launch a flash client rather than a hard client. I will keep searching for a more elegant solution, so check back often.
I had to do a simple update to a xmpp messaging server this past week to fix a problem with IE hanging on a close of a ajax window. The problem can be described here, here and here. Basically when we open our flash IM window and close that window within the same browser session, a new launch of the IM window would not occur.
It was suppose to be a quick update, tweak one parameter to lower the BOSH timeout and restart the tomcat server. It should have taken 10 minutes, maybe 20 with testing, to complete this update. I left the office two and a half hours after I started the update. Seems the networking guys were doing some firewall work that “should not have any effect” on my work, but rather than pointing the VIPs to one data center at time, well they pointed the external DNS name to both data centers.
So I wasted about 2 hours chasing ghosts. Sometimes work is just too much work. Oh by the way.. It looks like the update did not work
Comments (0) 
