How can i restore a previous leak period?
Example, we have our server set-up to calculate the leak period based on version number. Unfortunately someone bumped the version number of the project prematurely. We restored the version number and the change is reflected in the project history, but the leak period metrics were not restored. Currently the newer,erroneous version number is being used to label the leak period.
Side question: How does sonarqube detect a "newer" version number? Does it just look at the changed string or does it have to be higher?
Using microsoft windows as an example: If the project version change from 3,3.11, NT, 98, 98 r2, ME, xp, 7, 8, 8.1, 10 how will sonarqube calculate leak periods?
I was able to solve this by going to the project history and deleting the snapshot that caused the version number to change. It seems to revert to previous leak period next time the project is scanned.
I'm not sure there is any other bad side effect to this yet, but at least the reports are more correct than before.
Related
In my environment we are using Windows 10 Pro version for analytical applications. Sometimes unexplainedly time and date was going to back date.
We have changed the cmos battery, but after half a week of the analysis the date and time got changed again.
This type of issue may lead to data integrity issues.
Any suggestion on this is appreciated.
It may be, that Windows 10 updates the time and does not know where it is. It may then apply a different time zone.
I would turn off automatic date changes in the settings first and then see if this is the issue.
There is software that synchronizes the time with an atomic clock. This would probably be better if you rely on the time and have an internet connection available.
We have a client side webstart application that is not yet ready for Java 9, it's rather unclear what will happen on 21.9.2017 with the auto-update option in the jRE.
If you have the latest Java 8 version with the auto-update enabled. Will version 9 be pushed to the client? Is disabling the auto-update function the only option to prevent this or will the auto-update only look for new versions of java 8?
Will version 9 be pushed to the client?
No.
New Java versions take some time to percolate to unsuspecting users:
Even after the GA release of Java 9 will Java 8 remain the default download option at Java SE Downloads for about six months. (Turns out that was wrong.)
Java 8 will receive further public updates until at least September 2018.
Only when that time window draws to a close and Oracle published its official "end of public updates notice" will hesitant users have to consider switching to Java 9.
A few months before the end of public support will the auto-updater propose an update to Java 9, but it will require user permission. (At least that's how it worked between Java 7 and 8).
Disabling auto update is not required, and is actually counter productive.
Keep in mind that people have legitimate reasons to continue using JREs or JDKs for Java 8 (probably several years into the future).
It is very much the same as with previous major releases of Java: ideally you plan about moving forward at some time - but there is absolutely no side forcing you when to make that move.
We started using Java 8 for production like 12 months ago - and we still have products out in the field that run on Java 6.
In that sense:
you educate yourself about the changes that Java9 is offering
you mainly identify a "path forward" for your deliveries around the new module system
you start experimenting with Java9 at some point ...
and then, when you decide "we are ready" - then you move forward.
I believe no,
as JAVA 9 has SO BIG change caused by its jigsaw(the change is so huge and make java 9 delay again and again ), such big chance has potential to break your current java application.
BTW: java 9 will finally release in this month.
When mongodb is creating a new file under data directory it takes more time to create :
Line 376: Thu Jan 15 18:01:49.407 [FileAllocator] allocating new datafile >\data\db\test.3, filling with zeroes...
Line 476: Thu Jan 15 18:03:55.650 [FileAllocator] done allocating datafile >\data\db\test.3, size: 512MB, took 126.242 secs
Because of that node give below error after that node is not able to connect with mongodb.
{ "error":"{ err: 'connection to [localhost:27017] timed out' }","level":"error","message":"uncaught exception: ","timestamp":"2015-01-15T20:45:03.702Z"}
My understanding is that this error is coming from MongoMQ lib. I am not sure how I can handle it. Any one can help on this issue.
Windows Answer
The most obvious issue which could apply here is if you are using Windows 7 or Windows Server 2008. An issue (SERVER-8480) with those operating systems, which can be fixed by applying this hotfix means that the data files being allocated by MongoDB must be filled with zeroes.
That is a lengthy process when compared to the normal method. Unfortunately, even with the hotfix installed, with versions 2.6 and 2.4 MongoDB assumes the problem is still there on Windows 7 or Server 2008 and zero fills anyway. Version 2.8+ fixes the problem by detecting the hotfix specifically and reverting to not zero filling.
To give you an idea of the difference, here is a sample log line from 2.8.0-rc5 (which detects the fix) on Windows 7:
2015-01-22T16:56:51.749+0000 I STORAGE [FileAllocator] done allocating datafile E:\data\db\280\test.2, size: 2047MB, took 0.016 secs
And here is a sample log line from the same machine doing the same allocation with version 2.6.5:
2015-01-22T16:47:33.762+0000 [FileAllocator] done allocating datafile E:\data\db\265\test.2, size: 2047MB, took 112.071 secs
That's 112.071 seconds versus 0.016 seconds. Windows 8/2012 or 2.8+ (once released, and with the hotfix installed of course) seem to be the way to go here if allocation is causing problems for you.
There are also several more general known issues with versions of MongoDB prior to 2.6.4 on Windows, most notably SERVER-13729 and SERVER-13681 which were addressed with 2.6.4.
The remaining issues are being tracked in SERVER-12401 and are dependent on this hotfix from Microsoft to improve flushing of memory mapped files by the OS. Unfortunately, that hotfix is only available for Windows 8 and 2012, it has not been made available for Windows 7 and 2008.
Hence, make sure you are using 2.6.4+ at a minimum and, if possible Windows 8 or 2012. It may also be helpful compare any performance seen on remote storage with a local disk to determine if that is a contributing factor.
Linux Answer
(preserved in case anyone else ends up here when using Linux)
This should only take a few milliseconds, if you are using a supported filesystem. I suspect you are using something else (ext3 perhaps?), or perhaps using a very old version of Linux.
The supported filesystems use fallocate() to allocate the data files, which is very quick. If this is not supported, then the files must be allocated by filling with zeroes, and that will take a very long time.
Even if that is the case, 126 seconds to zero fill a 512MB file is very slow, which indicates the disk is either slow/broken, or oversubscribed/saturated and struggling to keep up.
If you want to evaluate the allocation outside of MongoDB, I've written a small bash script to pre-allocate data files for MongoDB (for testing purposes), which uses the aforementioned fallocate() and completes in milliseconds for multiple gigabytes on my test system.
Since some days TortoiseSVN uses lots of memory when I want to commit also it takes 10 - 20 minutes before the changed files appear.
On normal use it doensn't use much memory only when commiting or comparing changed files.
As you can see the memory usage is not normal.
I have already reinstalled the newest version (1.8.10) but no difference.
Does anyone have any clue?
(the directory I am working in is 2 GB This includes the tempdata witch is excluded from svn and i am working on w7 x64)
Here is a Screenshot of the Icon Overlay settings i use
I had the same issue since I updated to (TortoiseSVN 1.8.10); excessive amounts of memory used and a each refresh of your view would increase this amount even further.
The new version 1.8.11 appears to have resolved the issue.
Since installing XCode 6 GM, it has been freezing and locking, showing the spinning wheel of death while I attempt to edit code that has syntax errors. Has anyone else seen this, and are there any known work-arounds?
I foolishly abandoned my cautious strategy of saving the previous version (Beta 7) and it appears that Beta 7 is no longer available for download. Are there any known archives of / for the link?
I have also posted to the dev forums and will follow up with a bug report, but it is hard to pin down the exact circumstances.
Edit:
Additonal Notes:
CPU: SourceKit Service is generally around 100%, but that has seem to have been the norm for the flavors of XCode, and the CPU seems to properly drop off when it finishes recompiling.
RAM: SourceKit is no longer exhibiting the memory leaks that used to cause it to halt and catch fire, memory does not appear to be a factor, and there are several ~ 5+ gigs to spare.
Environment:
Late 2012 Mac Mini, 16GB RAM
OS X 10.9.4 (to be fair, this was new today as well, driven by the requirements of XCode 6 GM).
That said, only the software changed today.
Update
Apple claims that this bug is fixed in Beta 6.1, for what it's worth.
You should look if you have any imports missing in your bridging header file. Sometimes even commented out imports will cause this behaviour. For me it was commented out Pixate Freestyle Cocoa Pod. I had to remove pod completely from my project to stop SourceKitService from crashing.
https://stackoverflow.com/a/25173389/527539
I can't say any of these fixed the issue, but they alleviated the situation:
I removed all playgrounds from the project tree. Saved them somewhere else.
I removed all objectiveC code from the swift project (when possible). This Spinning-wheel, BTW, is a problem only in my swift projects. My other Objective-C-only projects are fine.
It looks like it's the background indexing process which is taking all the CPU. Open "Activity Monitor" and see it right there at the top, using 360% CPU. Lowering the priority for this process helped as well (type in terminal):
renice 10 -p [pid]
Make sure to take the correct process id from Activity Monitor.
The higher the number (should not exceed 19) the lower the priority.
I make significant changes one at a time. It seems that the amount of errors in the file affect how many times and for how long the spinning wheel spins. It looks like some type of errors trigger it more often than others, but I'm not able to pin point which exactly.
XCode had a similar indexing issue in previous versions (see this Xcode4 issue: How to disable indexing in Xcode 4?) which gives me the hope they will fix this issue sometime, hopefully soon...
I create a new tab via menu File->New Tab and close the old tab that is frozen.
CmdT does not work that time.