The fix isn't in the mongo code, but rather the is os itself requires the hotfix. Check the mongodb windows installation instructions for ref. On Jan 20, 2015 8:45 AM, "Andy Seaborne" <[email protected]> wrote:
> > On 20/01/15 12:15, Rob Hall wrote: > >> I did randomly notice that mongo db had to have a hot fix for windows 7+ >> users that solved a bug associated with Windows memory mapped files. >> >> If this is a Java+Windows environment problem, that might be a clue as to >> what's going on. >> > > The build problem looks like resources, not java. > > The reason why TDB has Windows specific testing is the (in)famous: > > http://bugs.java.com/view_bug.do?bug_id=4715154 > > (and several others) > > Long time, won't fix, bug. (There are pragmatic, limited, JVM-specific > semi-workarounds.) > > If MongoDB have had a fix recently, I'd be interested to know more - my > Google foo wasn't strong enough to find it. > > TDB's test setup goes through hoops to workaround it and it leads to large > amounts of temporary file space that does not go away until end of JVM. > Plus users do sometimes want to delete a database awhile running. > > Andy > > Relevant hot fix: http://support.microsoft.com/kb/2731284 >> On Jan 20, 2015 6:04 AM, "Andy Seaborne" <[email protected]> wrote: >> >> This is repeatedly going wrong and I'm not sure why. >>> >>> On the surface, it looks like there is a rogue Jetty sitting on port 3535 >>> which then blocks the tests. >>> >>> But: >>> 1/ Tracing back to the last job to run at all (#507), it's some TDB/JDBC >>> tests failing for weird low level reasons. >>> >>> 2/ Switch between windows1 and windows2 slaves today gets nasty file >>> errors (various flavours - some clearly jenkins problems) >>> >>> 3/ I can't even wipe the workspace at the moment. >>> >>> so my guess is that OS resources are the problem and we can't fix them. >>> I've email builds@ to ask for help and disabled the job for now. >>> >>> We might be contributing to the problems; the windows builds being >>> resource hungry for mmap files, but the job was running fine for quite >>> some >>> time until #507 and I can't see any change that might be connected. >>> >>> Andy >>> >>> >> >
