All entries tagged with support
Wow... there's been nearly 4,000 hits to my blog entries regarding the GetDocumentByKey bug.
A lot of you have been asking me about an update so here we go:
The Short Story
The issue's reportedly been fixed. There is a technote where you can contact IBM for a fix.a technote where you can contact IBM for a fix.
As a nice side effect the original bug they were trying to fix all along (the "infinite loop" bug) is now truly fixed. Your apps that perform any GetXXXByKey calls will likely scale much better under load than they ever have.
The Long Story
I received a fix (8.5.1FP1 HF154) for Domino 32-bit on Win32. We applied for a client version of the fix but haven't yet received it.
The fix has been running for 3-4 days with no errors. But I only received errors maybe 10 times in the past 4-5 weeks anyway so we won't really know if things are fixed until a couple of months down the road. Personally I've received a bunch of hotfixes over the years and they've been all been perfect. I'm sure this is no different.
The technote instructs you to open a PMR to obtain for a fix for this bug. It is uncertain whether IBM will proactively contact customers about obtaining a fix.
This bug exists in the following versions:
7.0.4
7.0.4 FP1
8.5.0 FP1
8.5.1
8.5.1 FP1
8.5.1 FP2 <-- Not out yet, but likely affected
I believe this fix missed the 8.5.1FP2 window (it's due any day now) so the first formal release with the fix will be 8.5.1FP3 (probably due in May/June if the current release cycle times are any clue.) Here's how the fixed call works: If, after the first lookup, the view comes back "dirty" (i.e. there's been an update) then a refresh is forced. Once that refresh completes one more lookup is called. The result of that lookup is always returned, regardless of whether the view is dirty again or not. There's no way for the error to be returned.
So you're always guaranteed at most one refresh, and only if needed.
The remarkable thing about this is that a view can be considered "dirty" if there is time creep (as in my original post) or if there has been another doc update since the lookup's refresh was called. It turns out that the latter case is the main case where we would all encounter a dirty view -- any time our apps were under a load of doc updates. For example, if you've got an agent running that is updating many docs then in the past a simultaneous GDBK() call might have spun and spun for a long time until things settled down (i.e. your update agent paused or finished updating docs) and then finally returned a result. Throughout that time it will have kept refreshing the view, resulting in needless resources being consumed over and over. I've seen this personally where an agent creating about 5 docs a second would cause a GDBK() call to hang for 10-20 seconds or more before finally completing. This was likely because it was continuously refreshing the view until the update agent's activity slowed down sufficiently. With the fix the call will finish much faster (the time it takes to perform one refresh.) This means your apps that perform GDBK() calls in busy databases should scale much better and seem much more responsive. This is what IBM was trying to tackle all along, though the original technote is not very specific on this topic.
Some really great people helped out with fixing this problem. I'd like to publicly thank Chad Scott of the Core Server Team in Lotus Support for his assistance with my cases and Ed for his fast reaction time on his end. There was also some very good discussion on Ed's blog about the IBM PMR process in general. We really need a crowd-sourced way to discuss and search for bugs. To that end I've registered notesbugs.com and will hopefully do something interesting there in the near future.
Thanks to everyone for their support on this as well. Good luck obtaining your fix.
|
 Ratings
2
|
For those that were asking me, yes - IBM has finished a fix for the GetDocumentByKey problem. I won't steal any thunder about the formal announcement (also because I don't know all the details) but the way IBM explained to me how the refined algorithm works is awesome. So awesome, in fact, that you may see your apps scale much, much, MUCH better under load than ever before. I'll go into more detail after the formal announcement, but this fix (really a more-correct implementation of the infinite-loop fix) may be yet another reason to get on 8.5.1, ASAP!
|
Ratings
0
|
We were downloading in London from a Domino server in Florida. Domino was serving the file at a whopping 65K/sec to London, despite being on a connection with about 8 MB upstream available and the London connection having tons of available downstream bandwidth. Running an FTP server on the same machines allowed the same file to be transferred at about 600K/sec.
HTTP transfers are slower than FTP but not that much slower. So we opened a PMR. The answer is this SPR on Windows:
SPR # MKIN7TGMQV Fixed in release: 8.0.2 FP3, 8.5.1
Product Area: Server Technical Area: Web Server Platform: Windows
Lotus Customer Support APAR: LO45289 What is an APAR?
SPR# MKIN7TGMQV - Fix for Windows, where we had performance problem on high latency networks. We added/changed code to reduce latencies by changing how the winsock layer is used and by increasing the buffer size of network writes.
Apparently Microsoft changed the Winsock layer interface when they released Windows Server 2003 but didn't tell anybody. The old interface (which IBM was using) became worse while the new one was the latest-and-greatest (which IIS, surprise surprise, was using.) The end result is that a user's transfer speed was heavily influenced by their latency. E.g. with 60ms of latency you might get 240K/sec. With 80ms of latency you might get 180K/sec. And in our case (160ms or so) we were getting 65K/sec.
Installing a hotfix for this SPR brought that server's HTTP transfer speed up to around 400-450K/sec to London.
While this fix is great and all, the scary bit here for me is that IBM didn't notice this until 8.5.1, so sometime in 2009... about 6 years after Windows 2003 shipped. I hope that a high-latency network model is part of their test suite now.
|
Ratings
0
|
There's a growing number of fixes listed for 8.5.1.
And even one for 8.5.2!
Admins everywhere can rejoice!
|
Ratings
0
|
I'm crossing my fingers that I'm right (and this isn't just something that leaked that shouldn't have.) The Fix List database has an SPR listed for 8.5.1:
Fix List Database
Oh, and for the record, 8.5.1 is currently in BETA, might be subject to change prior to release, etc. etc.
|
Ratings
0
|
UPDATE: Here's a link to this idea on IdeaJam.
So XPages are cool. VERY cool. And since they can be bolted onto an existing Notes app you should be really, REALLY tempted to upgrade your existing Domino web apps with screen-by-screen updates.
Simply rewrite a form/view/etc. as an XPage and leverage all of the CSS and JSF goodness, give your users a better experience, give your app better performance, etc. And you can finally code stuff where it's supposed to be, without having to use all of the hack-tastic legacy Domino web techniques.
But there's one big hurdle here: XPages don't work with LotusScript. At all. So those legacy apps, if they use WebQueryOpen or WebQuerySave agents, are looking for a forklift-style upgrade where you get to rewrite your agents and script libraries in Javascript and/or Java.
So a cool new technology requires a massive rewrite? Hmm.... sounds kinda like Microsoft.
But wait, it gets worse. The Notes client doesn't support XPages (yet). Oh, I'm sorry - did you need to use that app on the web AND in the Notes client? Well now you get to maintain your Lotusscript libraries for the Notes client, all while maintaining new Javascript/Java libraries for XPages on the web, right? Certainly you're ready to double your dev and testing efforts.
I know, I know - Notes 8.5.1 will get XPage support in the Notes client. This may mean we finally have a single dev road where we can simply write an app in XPages and it Just Works(tm) in browser or client. And that would be really, really fantastic. But (as far as I know) Xpages still aren't going to support LotusScript. So, again, any legacy apps will need major rewrites to take advantage of the new front-end.
I'm sure Lotus development saw this coming a mile away as a shortcoming of XPages. It was asked about in forums for the Notes/Domino 8.5 Beta, and also the Gold release. There's even a Wiki article that tells you how you can have an XPage run an agent (which could be an LS agent) as a pseudo-band-aid to try to help on some things. Unfortunately that approach is riddled with shortcomings, such as requiring that you save your doc(s) prior to calling the agent (even if you're not certain you want to do so yet) and foregoing all XPage error encapsulation. All your XPage can do is say "Hey man, I kicked off the agent, ok?" And recreating the functionality of a WebQueryOpen agent? That's even more fun.
Naturally, I opened a PMR for this, asking to be added to the enhancement request to have XPages consume Lotusscript. But you know what? THERE WASN'T ONE. Not a single SPR relating to this.
Now, certainly Lotus development has talked about this. Certainly Design Partners have mentioned this on conference calls. Certainly there was feedback about this in the private Betas. I'm sure Nathan's shouted loudly that this is a huge barrier for legacy applications. But for general customers this is the only formal means at our disposal to ask for this type of thing.
So if you too would like to see Lotusscript support in XPages, open a PMR and ask to be added to SPR# PALT7SVH29 .
|
Ratings
0
|
