• Browse Blogs
  • My Blog
  • My Updates

+Tags Get help with tags?

  • View as cloud  | list

+ Similar Blogs

photo

Big Mutant Bl...

49 Entries |  Michael Smelser
Updated 
RatingsRatings 1     CommentsComments 49
photo

Uh Clem's Adm...

54 Entries |  Chris Mobley
Updated 
RatingsRatings 8     CommentsComments 55
photo

CrashTestChix

100 Entries |  Marie L Scott
Updated 
RatingsRatings 13     CommentsComments 226
photo

TexasSwede

109 Entries |  Karl-Henry Martinsso...
Updated 
No RatingsRatings 0     CommentsComments 94
photo

Patrick Picar...

62 Entries |  Patrick Picard
Updated 
RatingsRatings 2     CommentsComments 112

+ Bookmarks

+ Blog Authors  

1 - 5 of 5
  • Previous
  • Next
  • Page   1

Some Downtime Wednesday Evening

Chris Whisonant |   | Tags:  infrastructure bleedyellow downtime | Comments (0)  |  Visits (569)
Tomorrow evening (Wednesday, June 24, 2009) we will have some downtime on almost all of the BleedYellow servers. This includes the Connections and Sametime servers. It's a planned, routine maintenance outage to load some fixes, etc...

Thanks!

No RatingsRatings 0

How Google Killed Old Yeller!

Chris Whisonant |   | Tags:  connections bleedyellow issues | Comments (1)  |  Visits (818)
As many of you may know, we have had a problem with Dogear here for a while. At one point, I started referring to it as Old Yeller (could not resist the dead dog/yellow reference - sorry). After doing a lot of upgrades (to IHS/WAS/Connections), DB troubleshooting, completely deleting the DB (which has since been restored), enabling advanced Windows logging (which did not help much), even moving to a fresh VM with a clean install of WAS, maintenance, etc..., nothing seemed to work. In all the crashes of the Dogear jvm, only once did a good Dr. Watson dump get sent out. But in one of them we noticed what looked like a strange search of the Dogear database. After further digging, I looked at this closer with IBM. Turns out we were seeing a lot of these in the IHS access.log:

image
It was not always the same search - it would be for different users, etc.... The IP address, though, is a Googlebot. So, in walks robots.txt to see if he can help! After adding it to the server, I wondered how long it would take for Google to honor the settings as we kept seeing the crashes. As part of the move to a new box with Deployment Manager, the Dogear jvm would automagically restart. So that helped uptime a bit. ;) I noticed that the last crawl of Dogear by Google was around 8:25 PM on 6/12/09. And at 8:29 PM Dogear was last restarted. So it appears that Google took around 12 hours to start honoring the robots.txt.

After running now for almost a week, I think we are confident in saying that Dogear has issues with this type of string in the crawl. After some further data crunching from 6/12/09 (where we logged 7 Dogear crashes between 7:11 pm and 8:30 pm), here are some quick stats on when we saw Dogear get crawled with this string in the IHS access.log and when the server recovery message was logged in the WAS SystemOut.log:

the string "lang=en?ref=sex%" was found in IHS access.log
6/12 19:07
6/12 19:12
6/12 19:25
6/12 19:43
6/12 19:50, 19:52
6/12 20:06
6/12 20:25


Restarts in SystemOut.log
6/12 19:11
6/12 19:15
6/12 19:29
6/12 19:44
6/12 19:57
6/12 20:11
6/12 20:29

Since those times on 6/12, the crawl has not occurred any more and Dogear has not crashed. Here's to hoping this is finally resolved!

No RatingsRatings 0

A Note for BleedYellow Bloggers

Chris Whisonant |   | Tags:  blogs bleedyellow dogear | Comments (2)  |  Visits (713)
To all of our wonderful bloggers here, you are probably aware of the issues we have been working through with Dogear. This has the potential to make your blog appear unresponsive when Dogear hangs before automagically restarting itself. Before it would just die, now it restarts. If you have the "Dogear Bookmarks" available in your blog template, then this is what causes your blog to take a while to load sometimes. If this gets too irritating for you, you can modify your template to simply disable the Dogear integration (at least temporarily until we get this sorted out).

Thanks!
No RatingsRatings 0

DAOS Confusion!

Chris Whisonant |   | Tags:  domino attachments daos administration | Comments (2)  |  Visits (1,111)
Or: Can I DAOSify a Server With < 8.5 Clients?

Recently I have had some colleagues and clients asking about updating a Domino Server to 8.5 and turning on DAOS while still running a mix of 6 and 7 Notes Clients. There is some confusion related to some upgrade seminars that are happening that appear to be using this slideshow. Here is slide 18 that is causing some confusion:

image
The last bullet is causing confusion. Of course "Domino 6 and 7 clients will not recognize DAOS" - even the 8.0.x client would fall into this category as it was released pre-DAOS - DAOS is a server feature. However, there are no known problems with using an older client against a DAOSified mail template. Here is why: the Domino Server is aware of DAOS. Any requests for an attachment from clients, servers, or services such as BES will be honored by the Domino server sending the attachment. The server will still have to get the nlo file and serve it to the requesting client (or server) over the wire. And, if you are running local replicas it does not matter either because the replica will be pulled down with all attachments inside the database.

Do I recommend a long-term strategy of having 6 and 7 clients with an 8.5 server? Negative. But you can immediately reap some benefits by upgrading your server and enabling DAOS while you are working on your client rollout strategy. And, as the slide above states, you'll need to wait until the clients are upgraded before you can update the template to mail85.ntf. Finally, DAOS is not just for mail databases. I have also sensed some confusion around this. Of course, in most environments, the mail store is where most databases would have duplicate attachments (either internal or shared) and most of DAOS's storage and i/o savings has been revolved around mail files.

Hopefully this helps!
No RatingsRatings 0

Re: FTOTM (first Tuesday of the month) = new rules

Chris Whisonant |   | Comments (0)  |  Visits (553)

In response to: FTOTM (first Tuesday of the month) = new rules

I never knew that you could actually disable xPages on the server completely. This is rather interesting. What's funnier is that the notes.ini that's used to do this is INOTESDISABLEXPAGECMD - iNotes and xPages are not even tied together at this point.
No RatingsRatings 0

  • Previous
  • Next
Jump to page of 1
Skip to main content link. Accesskey S
IBM Lotus Connections Help Tools About