We are facing memory leak issue with ConfigurationProviders ConfigurationRoot.
Looks like this issue may have been fixed
https://github.com/aspnet/Extensions/issues/861
However, Microsoft.Extensions.Configuration 3.0.0 requires NETCORE 3.0. Can someone please confirm how this fix can be applied with .NETCore 2.2.7? We do not want to upgrade to NETCORE 3 yet, as we have time constraints for project delivery.
This is specifically related to the reload change token, so I would assume disabling reload on the JSON files would negate the issue. That means you'd have to restart your app if you made any changes to the JSON files, but that really shouldn't be much of an issue, as you should really only be making configuration changes as part of a new build and deployment anyways (via your CI/CD pipeline).
Otherwise, no, you'd have to upgrade to Core 3.0, unless this fix gets back-ported into the 2.1 LTS release. That's actually a possibility, so it might be worth calling it out on the issue, since a memory leak is a pretty serious issue to leave unchecked in an LTS release. It might have just flown under the team's radar.
The other possibility is that is is back-ported into 2.1, but since you're on 2.2, it's not there. I'm not sure if they'd necessarily back port it into 2.2, since that's not an LTS. As such, your choice may boil down to down-grading to 2.1 or upgrading to 3.0. That's the breaks of the game when you're not not on the LTS release - upgrading may be required.
This issue has been sorted, see details here
https://github.com/aspnet/Extensions/issues/2576
Related
I'm maintaining some js library. Releases follow SemVer. Current stable version is 1.5.0. I'm working on 1.5.1 and have 1.5.1-beta.2 which is published at npm with "next" tag. Today I got bug report, discovered the issue and ready to fix it. The thing is that 1.5.1 is not going to be finished during nearest days, it turned out to be more complicated than I planned initially. But I want the fix to be published.
What is the right strategy in this situation? Obvious approach which I'd like to avoid is to postpone the bug fix until 1.5.1 is done and published and then release 1.5.2 containing the fix.
Another way is to publish the fix as 1.5.1 based on 1.5.0 and then continue previous work switching it from 1.5.1-beta.2 to 1.5.2 or even 1.6.0. I'm concerning about inconsistency with the result chain in this case:
1.5.0 → 1.5.1-beta → 1.5.1-beta.1 → 1.5.1-beta.2 → 1.5.1 (bug fix, based on 1.5.0) → 1.5.2 (based on 1.5.1-beta.2)
How such collisions are being addressed using SemVer?
Okay, so you have bug set A currently baking as 1.5.1-beta2 and you have a new bug set B that you want to get the fix out for immediately. The correct mechanism for this is to fork 1.5.0, fix bug set B, and release 1.5.2 (assuming you don't need a beta). Then merge your B fixes into your A working branch and release 1.5.3-beta1 and proceed to drive that to an official release.
It gets a little more complicated when you have two parallel beta sequences running, particularly when you're not sure which is going to make it to release first, but it is manageable. The key is to to just keep in mind, how SemVer precedence impacts the decisions your customers make (the algorithms they apply), whether to fast-track a particular version into their production systems, verses how their developers pull bits from you.
My production systems, have two inputs:
Development is the product of my engineers.
Automated maintenance is the product of a system that:
Pulls patch releases and applies them to a fork of my current production code.
Tests the applied changes against an extensive suite of functional and performance tests.
If the tests are green, flight tests the changes in my production environment, while monitoring for unusual changes in production failure rates.
As long as everything is going well and a human doesn't step-in to stop it, eventually rolls out the changes to the entire production system.
There are of course, variations for services and packaged products. The point is, you can use your release points to signal to your customers automation, or developers, that you have an important bug fix that has little risk of breaking anything. There is no requirement that 1.5.2 have any lineage back to 1.5.1-beta#. You are not required to ever release a 1.5.1. It is customary however to add a comment in your release notes that 1.5.2 is a hot fix for the bug in 1.5.0 and does not contain the fixes in 1.5.1-beta#.
While you may never encounter a need to do so, you don't have to include the bug fixes from 1.5.2 in your eventual 1.5.3 release, provided the later release, passes your quality controls. It is sometimes the case that a specific bug fix, winds up not being applicable in later releases.
How you maintain your product quality is entirely up to you. How you signal the level of risk/importance for a specific release, is defined by the SemVer standard.
I have an application using JRuby 1.6.7, Ruby 1.9.2, Rails 3.1.3 and Warbler 1.4.0.beta2
For a while now, I have been trying to update the application to use JRuby 1.7.x. Every time I tried (with versions 1.7.3, 1.7.4, and most recently 1.7.6) I would get the following error:
org.jruby.rack.RackInitializationException: No such file or directory - /home/production/var/tmp/Jetty_0_0_.war/webapp/WEB-INF/lib/gems.jar!/gems/activesupport-3.1.3/lib/active_support/locale/en.yml
After some help from this question here: Warble not including active support locale files, pin pointed that that issue was with the warbler configuration in my application. We had enabled the following configuration:
config.features = %w(gemjar executable compiled)
Specifically, the gemjar feature was the one causing the issue. With that feature disabled, everything works fine (the WAR deploys perfectly)
I am wondering, if anyone else has run into this, or if anyone knows what the issue might be?
And then more specifically, what are the disadvantages to disabling the gemjar feature of Warbler? From what I can tell, there shouldn't theoretically be anything devastating by disabling it... but I may be overlooking something.
(I do also wonder if the full warbler 1.4.0 release might fix this... but I can't find anything about when a release might be coming out)
there are none - actually running a .war with gemjar might have issues on some servers (esp. if they do not expand the deployed .war, since then it's quite hard to reference files/resources packaged in a .war while still inside a .jar). on the other hand it should roll fine if things are expanded (even with gemjar) ...
you should definitely report this with Warbler's repository (if not reported already).
it should not be hard to fix - likely a one liner, I know a PR would be most welcome :)
NOTE: on the other hand if it worked in a previous JRuby and updating 1.7.x is the issue, than it might be a "regression" on JRuby's side and they might actually fix this if they knew about it ...
I'm starting a new project that'll require Mono and mod_mono to run under CentOS. There are two versions of Mono: the release which is 2.10.8, and the development branch, which is 3.0.7 as of today.
I'm wondering what would be the right version to start. Obviously the stable version would be my choice, but I'm not sure what Mono 3.0 adds that could be missing from 2.10. Note that the project will be ASP.NET 4.0, using MVC4.
What version would be recommended? The stable but older one (dates back from 19-Dec-2011!) or the more recent one?
Mono 2.10 supports ASP.NET MVC3, since you want to use MVC4, you'll have to use a later version.
More recent versions of Mono have solved a lot of issues in 2.10, including issues related to ASP.NET.
So you may want to go for a more recent version. I don't think stability will be an issue,
but you will have to perform proper tests to determine if the version you are using supports everything you are trying to do in your application.
Don't deploy to production without testing.
UPDATE: Correction, there is 'partial' MVC4 support in 2.10 and no support for async.
So while you might be able to use 2.10, your mileage may vary depending on what features your app uses
I have an OSX application written in Objective-C/Cocoa using xcode. The application is quite finished, tested and sold on the App Store.
I haven't worked on this application for some time and recently, I rebuilt it using xcode 4.3.3 on my OSX 10.7.4 and I noticed that while it builds just fine, there are some very strange visual glitches when running the application that were never seen before and occasionally, I get EXC_BAD_ACCESS when closing the application. All these seem to be related to the PDFKit framework I am using. I am unable to debug these problems since the glitches are just visual (nothing I can check in code) and EXC_BAD_ACCESS exception comes from internally allocated objects not related to my code.
The code itself haven't changed, I tried previous revisions of the code and they all exhibit the same strange behavior now. I tried running an old binary I have of the application (compiled couple of months ago) and it works just fine. Then I tried building it with previous versions of xcode, down to 4.2.1 (which I know was ok when I submitted the app to the app store) and the problems still occur.
Then I suspected this may be something specific to my environment so I built the project on different machine also with xcode 4.3.2 and OSX 10.7.4. Same results, the problems are still there.
So now I suspect that it has something to do with the OSX 10.7.4 update since this is the last thing that was changed between now and when I was able to produce a good build of the application. I am pretty puzzled to what to do next and how to identify the cause of this problem. I have an old binary that is working fine and I have a newly compiled binary of the same code revision that has problems.
Is there any useful information I can get from the difference of these binaries? What can I do to determine the cause of these problems? What can I try next?
Thanks!
NOTE (update): I stated it above but I want to make sure it is clear. This is a Mac OSX Cocoa application, not iOS.
just reset your simulator then try.
I hope you check the ARC information
go to your project Target set build settings --> Search Paths-->Always Search User Paths Set Yes.
And check your all class variables different from one another.
Xcode--> preferences-->Documentation check installed core Libraries (or) install it
like that
Xcode--> preferences-->Components check required component installed or not
check these things in your project.
Are you sure your customers are not having the same problem? Since you have tested the application on a different machine you probably do not have corrupt libraries installed (unless you did not install from scratch but used some migration tool?), so that is probably not the problem.
Most logical explanation to me would be that your customers also have this problem but they haven't reported it yet. In that case, you probably have a memory problem and there are techniques to attack that.
In any case, eliminate all the parameters that you can eliminate to simplify the problem. Deconstruct the application until the problem does not occur anymore or reconstruct the application in a different project until the problem occurs again.
It sounds like a nasty one, but you'll get there in the end, with patience and perseverance :)
First of all, you need check and verify the build log for suspicious compiler warnings.
For EXC_BAD_ACCESS, XCode analysis will give useful information.
You could try 10.6 or 10.5 (need manual installation) SDK. Or restrict the deployment target to 10.5 or 10.6.
I will answer my own question (since none of the above answers really answer it) so anyone with a similar problem might have a hint. I was not able to understand why exactly this happens but I'm pretty sure this is not a problem with my code but rather some glitch on Apple's side. And there is a workaround.
First, I compiled Apple's sample "PDF Annotation Editor" project on my Lion 10.7.4 and while the functionality is obviously different from my project, it also exhibited similar glitches with the PDFView display that my project does when compiled with 10.7.4
Then I proceeded to building a fresh clean system on new hard disk. Intalled Snow Leopard and upgraded to 10.6.8 and ONLY installed xcode. Compiled my project (the source code always stays exactly the same) and everything works fine. No problems seen in the compiled project.
Updated my OSX to Lion 10.7.4 and xcode 4.3.3, same source code. The problem is there after I compile it. I am pretty sure that if I tried 10.7.3 first, I would not see the problem as I remember it only starts with 10.7.4 but Apple doesn't provide any reasonable way to update to 10.7.3 first or downgrade to it after 10.7.4 is installed (shame on them, not very developer friendly!).
So, the problem appears in 10.7.4.
Then I installed the pre-release version of 10.7.5. This was the only thing that was changed, same source, same xcode. To my surprise, the compiled code works flawlessly now and the problems seen with 10.7.4 are now gone!
So my workaround - wait for 10.7.5 release before working on the project further. Hopefully Apple won't screw it in the future with Mountain Lion. I don't think I am going to try and debug it further or submit a ticket to Apple, going to be a tough case to explain.
Thanks for the responses.
I have installed a fresh install of XWiki on a Windows platform.
The XWiki instance was installed using hsql for data storage.
The XWiki instance is hosted on Apache Tomcat.
Some of my users entered an apostrophe into the title of a page as well as the page content.
I received the following error:
http://jira.xwiki.org/jira/browse/XE-767
What is my next step to fix my broken XWiki instance?
Is there a way to upgrade a XWiki instance to a version that works? How do I save my existing content?
From reviewing the developers comments, it appears that issue has been corrected.
I, however, do not have enough background in Java or XWiki to know how I can move forward.
Thank you in advance for your help.
Indeed, the best solution is to upgrade to a newer version. Don't worry, upgrades are not that difficult.
http://platform.xwiki.org/xwiki/bin/AdminGuide/Installation#HUpgradinganXWikiInstallation
There are two parts in an upgrade: the platform, meaning all the files on the filesystem, and the wiki content, since quite often things change in the default wiki documents. Your specific bug can be fixed by upgrading the platform part, so if you're not too confident about upgrading the wiki content, you can just leave the old content in place.
In order not to lose your current database, be sure to leave the old "database" folder in place, and just replace the "webapps\xwiki" part.
From the error report the versions that fix the issue are
2.7 - http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterprise27
2.6.1 - http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterprise261
You can upgrade to one of them or to any following version, like XE
3.0 - http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterprise30
All versions can be downloaded from http://forge.ow2.org/project/showfiles.php?group_id=170
In a project that has such a rapid development cycle is very good to upgrade often in order to benefit from the latest features and bug fixes.