Lotus Nut

In response to: Concerns over DAOS Estimator?

Just a note - I have seen what Vitor is referring to in his comment on my initial post and have verified that there are cases where if the file name is the same as well as the size reported in the DAOS Estimator report that the files are treated as the same object by the Estimator. But after enabling DAOS on the database and compacting it, the two attachments were treated as separate objects by DAOS even though the tool did not see them as different. This means that you may save less space than the Estimator thinks due to some edge cases where you may possibly have attachments with the same name and physical file size but with different internal data. In Vitor's case with auto-generated files, the results may be very skewed. Again, each environment is different and ymmv. IBM is already aware of these findings above. :)

Paul Mooney reminded us the other week that we should do this - and I agree! Over at Vaughan Rivett's blog, he's discussing some of the misunderstandings surrounding DAOS. He brings up several good points, but does question whether DAOS should be enabled on mail.box files. Of course, each situation may be a little different for every environment, so it's up to you to determine if you want to do this. But keep in mind that, like Vaughan states, DAOS is for any application - not just mail!

If I'm a daosified mail user and am using a CRM application to save a copy of an email message directly into the CRM, then if DAOS is enabled for the CRM application the attachment will be shared in DAOS! But if I want to send that email to a colleague and mail.box doesn't have DAOS enabled, then that attachment will be written to mail.box and then when it's delivered to the recipient's mail file DAOS would associate it as a duplicate from my mail file. But, if mail.box has DAOS enabled, then the attachment will never be pulled back out of DAOS (meaning there will not be the disk i/o associated with the transaction) and the router will know that it already existed in DAOS and not try to pull it back out. So, in most cases you will want to enable DAOS on your mail.box files. (Of course multiple server hops will not be aware of this currently, but for mail users on the same server it should be ok.)

Also remember that you'll need to enable transaction logging on your mail.box files. This may mean that you will need to disable the notes.ini settings for MailBoxDisableTXNLogging=1 and/or RM_NO_LOG_LARGE_OBJECTS=1. You will also need to manually enable transaction logging on the database with the router off by using load compact -T on each of your mail.box files.

Yesterday in the Twitterverse, there were some concerns over whether the tool is accurate. I decided to do a quick test. I did notice today that there was a v1.2 of the DAOS Estimator Tool released on February 19, 2009. So I ran the latest version of this tool on a single database and I can see where the concerns may be coming into play.

The concern was that the Estimator Tool was only looking at the file name to determine if the attachment was a duplicate. Here's what I did to test this concern:

• Created a new mail file
• Created 2 draft messages that had the same attachment (attach.ppt) that was 699Kb
• Created a 3rd draft message with an 880 Kb attachment (also named attach.ppt). This was a completely different file from the start - it just has the same name.

The results were right in the main file analysis section - you can see that it saw 3 files in the DB with 1 duplicated file resulting in 2 DAOS files. So far, so good. But the problem is with the section I have outlined in red below. As you can see, there are two lines that have the same text ("Total Duplicate Attachments found"). This isn't right.



I went back to review some previous results (gathered from v1.1 of the Tool) and can see that the second line should really be "Total DAOS Eligible Attachments" (see image below). This explains some of the confusion with the above image. Using the wording from below in the results above, this is right. There's only 1 attachment that's duplicated but 3 total attachments that will be moved over into DAOS.



I've reported this to IBM, so hopefully this wording will get corrected in a v1.3. I think we can feel safe that the Tool is working just like DAOS will work in properly determining if an attachment is really a duplicate or if it just has the same file name. Though I certainly welcome any feedback otherwise!

Let's consider that for some reason your Connections server went down due to, say, a major power outage. Everything comes up ok except for Blogs (it could be another service as well, though) and you are getting the following error message:



When I was thinking about why this could be happening, I thought that either (a) there was a key file that was open but got corrupted, or (b) hopefully I just need to clear the Blogs cache directory because of corruption there. To make a long story short, it appears to have been a problem with the cache (whew...)!

The cache for a WAS server application is here:

[WAS_ROOT}\profiles\{Profile}\temp\{Node}\{application}

In this case it was:

C:\IBM\WebSphere\AppServer\profiles\myprofile\temp\mynode\BlogsServer

Basically, I shut down the server process, moved all of the files in the BlogsServer folder over to another location on the disk, and then started the server to let it create the temp files again. Thankfully, everything came back up alright. Oddly, the Homepage was rendering the blogs widget just fine - it was just the direct URL that wasn't working.

By default, BES debug logs are enabled at installation. They are not only enabled, but they have no roll-off time specified. I have seen this cause drive space issues (not to mention performance issues associated with so many heavily fragmented small files...)

To remedy this, you can open the BlackBerry Server Configuration and go to the Logging tab. From there, you will need enable the "Debug log auto-roll" and specify the number of days you wish to keep the logs in the "Debug log maximum daily file age" settings. In the example below, we will only be keeping 30 days worth of logs. After restarting the BES task and all of the BlackBerry Services, the files will be automatically purged.



Some notes:

You may just wish to restart the entire server instead of each of the individual services.

The daily folders will still exist, so do not panic if you still see them. They will exist because of three log files. By default, all BB phone calls are also logged. This is how your phone call logs get restored when you activate a new device. There are also some 2 SMS and PIN messaging log files. These are empty files by default, but administrators can enable this logging (without you being aware of it, by the way - you did know this, right?).

So go ahead and clean up your BES servers and try to remember to modify these logging parameters when you install the server (note to self...).

Kieran Reid has posted a great how-to on this. I just wanted to add something to what Kieran mentioned. For the MetaWeblog API url, you must use https in order for this to work. So, please head over to Kieran's blog and set this up for yourself. I just setup my blog with Scribefire, and that's where I'm posting from.

Cool UI thing in Scribefire: I copied the URL for the link above and when I clicked the "Add a link" button in Scribefire's editor, the URL was automatically pasted in. Nice touch. I think I'm going to like using this...

After seeing the security problems with Sametime Connect Client API that Carl Tyler blogged about over the weekend, Lotus 911 has decided to disable plug-in installation for the im.bleedyellow.com Sametime Community. Hopefully, this will be a temporary change until IBM releases a fix for this.

If you experience any issues with this, please post a comment here or use the "Contact" link at the top of the page.