My Nexus version is 2.5.1-01. I have added Central repository (http://insecure.repo1.maven.org/maven2/), but the Routing tab shows below error message
Remote strategy prefix-file detected invalid input, results discarded: Prefix file entry count exceeds maximum allowed count (10000), refusing to load it.
I found that this was a known issue https://issues.sonatype.org/browse/NEXUS-10233
But the mentioned workaround didn't work for me. Could it be because of my nexus version that provided workaround is not working?
That is possible, 2.5.1 was released in 2013 (3 years before the fix to NEXUS-10233). Highly recommend upgrading, it'd fix the issue if that's the issue you have anyway.
Ref: https://help.sonatype.com/display/NXRM2/Download+Archives+-+Repository+Manager+OSS
Related
In our company we recently upgraded to artifactory-pro:7.38.10 from version 6. To cleanup old artifacts we are using lavatory which runs an aql-search to identify the artifacts to be removed by filtering them by the date. This worked without issues our previous installation based on artifactory 6. Now after the upgrade artifactory frequently crashes with an OutOfMemoryError and the instance seems to require either significantly more memory than before or there is a memory leak. After further investigation it turned out that when problem is caused by running the aql-search and the memory usage jumps from 4 GB to over 10 GB. That's +6 GB for something that hasn't changed.
After searching for known issue I found https://www.jfrog.com/jira/browse/RTFACT-26825 which is resolved and might solve our problem but there is no version specified containing a fix. Since there is a workaround and the issue was fixed, I expect that there must be a release.
Is there already a release containing a fix?
The JIRA that you are referring to is fixed in the Artifactory version 7.38.0. So mostly, that should not be causing an issue as you are in higher version than 7.38.0.
In order to confirm, you may try the below. Add the system property to $JFROG_HOME/artifactory/var/etc/artifactory/artifactory.system.properties file and restart Artifactory for changes to take effect:
artifactory.nuget.v2.search.page.size=1000
Alternatively, you may put all the Nuget Devexpress repositories as offline. Now, check if you are encountering the memory issue. If you are not encountering this issue, maybe there is a regression issue. But according to my assumption, your server needs more resources as there are a lot of microservices introduced in Artifactory 7, when compared to Artifactory 6.
Please check if you are satisfying the resources requirement as mentioned in this page. In that case, you would need to tune your Artifactory as per this article.
I am evaluating a self-hosted artifactory installation on a trial license. I followed the official installation instructions for the docker container and the linux archive file. Neither of these installation options are working. The artifactory service fails to start.
I have opened an issue to track the problem: https://www.jfrog.com/jira/browse/RTFACT-27182
TL;DR; A component fails, a nasty stack trace appears in the logs, and eventually the services stop.
It would seem that there is a bug in artifactory. I have traced this back to multiple versions and this issue spans multiple years.
The problem appears to be that artifactory cannot get past the bootstrapping/initialization phase when started with artifactoryctl. At a certain point (around 2-5 minutes in) all the services stop and a pid file is left over, which is bad.
The workaround I have found is that the service can pass this initialization phase only after multiple start/stops (3 to be exact). In other words, we call artifactoryctl start, wait for all failures, then artifactoryctl stop and repeat two more times. On the fourth and final start, we will see the service come online (in about 150 - 190s). From then on, the service will start correctly with one call to artifactoryctl start.
I have not yet looked at the systemd unit file. My guess would be that it has/or could be made to have a number of retries to work around this issue and perhapse this issue does not exist when using the service wrapper.
I have also not yet looked again at the docker container which appears to be failing for the same reason. A workaround off the top of my head would be to modify the entrypoint script. If you were to dockerk exec into the container and try the workaround above it would likely terminate the root process and kill the container.
I have tried all the solutions which found on stack overflow, but still not able to resolve it. Somehow its not open the simulator and gives me error "unable to boot simulator".
I have reinstall 2 times xcode and also remove all simulator and add again. also change "DYLD_INSERT_LIBRARIES" to ZZ but no solution.
Please help me, Thanks in Advance!
Try to turn off System Integrity Protection http://www.imore.com/el-capitan-system-integrity-protection-helps-keep-malware-away - it helped me.
Problems:
As I also faced the same problem as below..
--"Unable to boot simulator"
--Storyboard designs/views completely invisible and showing only blue lines.
--CoreTelephony Trace File Error ... failed to create \tmp
Solutions
Don't do any SIP (Disable/Enable)settings its just temp solutions & it may harms to other applications in the mac as well as may affecting on secure data in the mac.
Best way to do upgrade your iMac to macOS "Sierra". It will solve all your problems.
Finally I am able to work on my project by solving above strange problems.
Happy coding.. happy Development...!!!
Assuming the error message was actually "Unable to boot the Simulator.", this error indicates an error starting up launchd_sim when booting the simulated device. In and of itself, it does not indicate the actual cause. You can look in ~/Library/Logs/CoreSimulator/CoreSimulator.log for more information about the error (including the error reason).
Possible causes:
On OSX 10.9 and earlier, DYLD_INSERT_LIBRARIES could be set by 3rd party applications. On later versions, invalid DYLD_INSERT_LIBRARIES are ignored instead of resulting in an error.
Usage of older simulator runtime DLC with Xcode 7 betas. Newer versions of Xcode ignore these older DLC.
If you need additional help, please provide that additional datum.
Also see my answer in the related question: Please see my answer on launchd_sim crashing: could not create temporary state directory regarding data you can collect to help further triage the problem.
After installing ASP.NET MVC 4 Beta, Visual Studio shows "Updating source control status" on the lower left side of the status area.
Any ideas? Seems a lot of stuff is broken after installing the beta. I am trying hard not uninstalling it.. :(
Issue is Nuget Manager. It installs templates for both ASP 4 and ASP 2.
Uninstalled Nuget Manager and then re-installed it (reopen VS Studio) and solutions come up in few seconds
I have the same exact problem! It seems to take forever to deal with TFS when opening a project.
I already uninstalled it once to verify (yes, it solved the problem). Now, I've re-installed and it came back with a vengeance. VS.NET locked up with loading my project :(
I'll post more if I get anywhere...
UPDATE: I waited longer and VS.NET wasn't locked up, it just took a really long time (5 minutes or so).
It seems that it's related to NuGet packages somehow, since my Source Control window has almost 1200 messages like this:
The item $/...[snip].../packages/AmplifyJS.1.0.0 already exists.
The item $/...[snip].../packages/AmplifyJS.1.0.0/AmplifyJS.1.0.0.nupkg already exists.
Every message in there is "already exists" for something in the NuGet "packages" folder
I'll keep you posted
UPDATE 2: I added a "Connect" bug. Go there and verify that you can see it too to get it more attention.
As Sonali pointed out, the issue is related to NuGet. On solution open, the NuGet package manager does a version control operation for every file in your "packages" directory. This issue should be fixed any day now in their 1.7 release by making it a one time bulk operation.
In the meantime, if you're using VS11 with TFS11, you can upgrade your workspace to a "local" workspace to eliminate the delay on solution open.
We were experiencing the same problem when opening projects...delays up to 10 minutes while the solution was loading. Our only solution after trying many suggested solutions via web searching, was to purge all deleted files for the project(s) in source control. Different solutions for different people seem to exist but if nothing else has worked, then maybe this helps.
I'm finding this problem in VS2013 Ultimate, but was not seeing the Nuget messages mentioned in other replies. The consistent message is "Updating source control status...", which can take upwards of 10 minutes to complete. It occurs at what seems like random intervals - I could be opening a solution, or typing out code, and UI lockup with the above message.
The solution that appears to be working for me now is to edit the devenv.exe.config file. Details can be found here.
Essentially you add one line to disable the default proxy. I hope this helps someone else.
I hate to ask the same question others have asked in Stackoverflow, but I still can't figure out why Installaware 7.0 R2 has this problem.
I need to build a installable CD for the previous version of my software. So, I am using what came with RAD Studio XE to do this. After creating a new Win32 setup for installation and customizing it, I built and test ran the project. In the middle of the installation, it raised an error, "Error Folder Path 'C:' contains an invalid character." So, I went back and created another win32 project and without doing any changes to anything I compiled, built and test ran the project. It worked without any error. After spending hours changing one thing at a time and testing it over and over again until I hit the error message again, I finally found the offending property in the Installaware. The error is raised thereafter once you change the Target folder textbox default value which is $PROGRAMFILE$\$TITLE$\ or Shortcut folder textbox default value which is $TITLE$. They only way to get passed this error is by not changing those default folder paths and allowing the user to change the folder path during installation.
It sort of annoying especially when you spend thousands of dollar purchasing these software from Embarcadero and Codegear. Is there a fix for this? Does anybody know?
These variables are resolved automatically to full folder paths. If you delete them or set an incorrect value, your package will not be able to resolve the installation path (hence the error). So the path edit controls should have valid default values.
If you don't want to allow the user to change your installation path, you can try deleting the dialog which offers this option. I'm not sure if that version of InstallAware supports it though.
If you don't like InstallAware, there are some good free or commercial alternatives which may help you.