Activator `.sbt.ivy.lock` is not available - sbt

I am trying to generate Eclipse and IDEA projects for a play project using activator. When I tried doing this, it does a little, but then it hangs at:
Waiting for lock on C:\Users\James\.ivy2\.sbt.ivy.lock to be available...
At first I thought my running session of Intellij IDEA may be conflicting, I killed IDEA and the issue persisted. I closed activator, deleted the lock file, and restarted activator, but then it recreated the lock file and gave me the same issue. This is the full log I have been getting.
[info] Loading project definition from C:\Users\James\play-java\project
[info] Set current project to play-java (in build file:/C:/Users/James/play-java/)
[info] Applying State transformations com.typesafe.sbtrc.SetupSbtChild from C:/Users/James/.sbt/boot/scala-2.10.2/com.typesafe.sbtrc/sbt-rc-probe-0-13/1.0-1a8f7afd5ba98b45834ff53dd349130c3ade22f1/sbt-rc-probe-0-13-1.0-1a8f7afd5ba98b45834ff53dd349130c3ade22f1.jar;C:/Users/James/.sbt/boot/scala-2.10.2/com.typesafe.sbtrc/sbt-rc-probe-0-13/1.0-1a8f7afd5ba98b45834ff53dd349130c3ade22f1/sbt-rc-props-1.0-1a8f7afd5ba98b45834ff53dd349130c3ade22f1.jar
[info] Updating {file:/C:/Users/James/play-java/}root...
Waiting for lock on C:\Users\James\.ivy2\.sbt.ivy.lock to be available...
How can I fix the lockfile issue?

The .sbt.ivy.lock file is used to synchronize access to your local ivy2 repository between several processes so they cannot modify the directory simultaneously. Usually the situation that you described happens when you have an IDE and Activator/sbt terminal running at the same time.
Even though you killed the Idea Process there could be another process spawned which was causing the lock so next time make sure that you kill all Java processes. However, the best solution for this issue is to avoid locking one process with another. So run only one process which uses the ivy2 repository at the same time.

If nothing works, the last step is to kill the .lock file.

I faced a similar issue, I was also getting the same error
Waiting for lock on C:\Users\ajain9\.ivy2\.sbt.ivy.lock to be available...
Then finally the issue was that there was another sbt process running on my system, and because of that the .sbt.ivy.lock file was not being available. As explained well by Daniel, lock file is used for synchronization purpose.
Once the previous process ended,I did not face this error again.

mac users, just do ps -ef | grep -i sbt, and kill the process

Related

Artifactory pro v7.30.x fails to start (multiple versions and installation methods)

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.

GlassFish: WARNING: GRIZZLY0023: Interrupting idle Thread

I'm seeing this error spewing in my log file for Glassfish 3.1.2.2:
[#|2019-01-18T18:52:34.603+0000|WARNING|glassfish3.1.2|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=36;_ThreadName=Thread-2;|GRIZZLY0023: Interrupting idle Thread: http-thread-pool-8080(1).|#]
I understand that I have a runaway thread but it looks like glassfish is not correctly killing that thread. Because when I do a jstack I still see the stuck thread. I saw in other StackOverflow posts that people suggest disabling the request timeout, but I don't want to disable this check because I need to be able to recover from runaway thread.
I know GlassFish 3.1.2.2 is old but I need this application to run until we have the resources to port/convert it into another environment.
I'm hoping its as easy as patch a few jar files and restart the server. Any help would be greatly appreciated.
Thanks!

waiting for lock on .ivy2

I am using activator for cloning a project.
I made eclipse.sbt to prepare project to import to Eclipse. after typing activator in cmd I face waiting for lock on C:\Users\Name\.ivy2\.sbt.ivy.lock to be available...
I guess it is locking because of eclipse.sbt, if it is so how can I prevent it?
Please check whether your IDE is downloading something, especially when you are running it your first time, it may take a while.
After the download is finished, you are able to run new command again!
Also, make sure you are not running 2 or more IDE or something, if that would not work, save your work and delete the lock file.
I faced a similar issue, I was also getting the same error
Waiting for lock on C:\Users\ajain9\.ivy2\.sbt.ivy.lock to be available...
Then finally the issue was that there was another sbt process running on my system, and because of that the .sbt.ivy.lock file was not being available.lock file is used for synchronization purpose.
Once the previous process ended,I did not face this error again
I was also facing the same issue. The Reason being there was another process (IDE), which was performing a sbt operation.

Any ideas why incremental flex compilation would not work for successive compilations of identical source?

I am running mxmlc in the command-line with -incremental=true. Flex is building the cache file using a checksum the first time. Subsequent compilations fail with this message:
Failed to match the compile target with path_to_cache/projectname_329043.cache. The cache file will not be reused.
path_to_cache exists
the cache file exists in path_to_cache
the compiler is not trying to create a new cache file, so I assume it is generating the same checksum
My environment:
Flex 3.0
Mac - OSX 10.4.x
I just ran across this issue myself and after not finding the answer anywhere on the web, I bashed my head against mxmlc in practically trail-and-error until finding the answer. In my case, I was regenerating the flex config xml file each time I compiled from within ant. It turns out that this is the error you get in the case where it thinks the config has changed. You can test this by simply touching your config file and running against unmodified sources. So, if the timestamp is changing on your flex config.xml between compiles, that is likely the culprit.
It could be a permissions issue. Have you tried running with sudo? I wouldn't recommend doing that permanently, but if using sudo makes the error message go away, then you know it's a permissions issue; and you can move on to the proper way to resolve it.
You could also try going into Disk Utility and doing a check/repair of disk permissions. OSX has been notorious for needing this done occasionally.

How do I debug a memory dump of a spiking ASP.NET process?

Sorry, I couldn't figure out a good way to phrase my real question.
I run a high-traffic ASP.NET site on a 64-bit machine. I have IIS running in 32-bit mode, however, due to some legacy components of the app. I am running this particular web app inside an application pool that has the web garden option on (running 6 processes inside an 8 core machine).
Once or twice a week one of the processes will skyrocket into 100% CPU utilization, causing a giant slowdown for the site, so my plan was to wait until that happens, memory dump the offending process, then poke around WinDbg to zero in on the thread that's spiking to see where the code is spinning its wheels.
I've debugged using WinDbg before to figure out what was causing a deadlock on the site, but that was several months ago and I can't remember how I got it working. (As a side note, this is a lesson to document everything you do.)
I'm running WinDbg on the Windows 2003 server that's running the site, so as to prevent any DLL version problems. Here have been my steps so far, please let me know where I'm going wrong to get the error message that I'm getting.
I first memory dump the spiking process using UserDump, with the following command, where 3389 is the ID of the process:
userdump -k 3389
I load the dump into the x86 edition of WinDbg.
Since I'm running 32-bit on a 64-bit machine, I first load the memory dump and then:
.load wow64exts
.effmach x86
I make sure that my symbol path includes the directory that contains my apps PDB files:
.sympath+ c:\inetpub\myapp\bin
Running just `.load SOS' fails with an error of "The system cannot find the file specified", so I go the fully qualified route of the following, which works:
.load c:\windows\microsoft.net\framework\v2.0.50727\sos
From here, I'm lost. I try any of the SOS commands, like !threads, only to get this error:
Failed to load data access DLL, 0x80004005
That error is also accompanied by the numbered list of items that I should be verifying.
I have verified that I am running the most current version of the debugger, mscordacwks.dll is in fact in the same directory as the mscorwks.dll file, and I'm debugging on the same architecture as the dump file.
I've also run the magical ".cordll -ve -u -l" command, but that doesn't solve anything. I'm always greeted with "CLR DLL status: No load attempts" when I execute that. Then I try ".reload", which yields a handful of warnings like "WARNING: wldap32 overlaps dnsapi". I wish it said something like "CLRDLL: Loaded DLL C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscordacwks.dll". But it doesn't.
Try executing !sw before running the sos commands. See this blog post.
(MSDN) How To: Use CLR Profiler
(MSDN Magazine) Investigating Memory Issues
In my experience, spiking app pool can be due to it being recycled. Have you tried IIS Crash / Hang agent and IIS Dump ?
http://www.microsoft.com/downloads/details.aspx?FamilyID=01c4f89d-cc68-42ba-98d2-0c580437efcf&DisplayLang=en
Also included with them is a dumpfile analyzer which will tell you about memory leaks and even suggest areas of your code that need fixing (complete with links to the applicable MSKB articles!)
Dude - not sure if this helps, but maybe try this.
Copy c:\windows\microsoft.net\framework\v2.0.50727\sos.dll to the same directory where windbg is installed to (eg. c:\program files\Debugging Tools for Windows\ ). Why? make it easy to load the sos file
run windbg
load the memory dump file. for me, i use ctrl-D or File -> open crash dump
.load sos <-- take note of the fullstop BEFORE the load command
.symfix c:\temp\debug_symbols
.reload
Ok.. take note of the commandline. this tells me the current THREAD that the dump was in. That might be useless for a HIGH CPU scenario .. because we could be in any thread.
so from here i look at the threads that were running and check out the busiest thread
8 !threadpool <-- this is so i can see the cpu utilization to check we are in a crap (busy) state... eg 100% cpu or what not.
9 !runaway <-- list the threads that have ben around the longest...
eg.
0:027 !runaway
User Mode Time
Thread Time
18:704 0 days 0:00:17.843 <-- Thread #18
19:9f4 0 days 0:00:13.328 <-- Thread #19
16:1948 0 days 0:00:10.718
26:a7c 0 days 0:00:01.375
24:114 0 days 0:00:01.093
27:d54 0 days 0:00:00.390
28:1b70 0 days 0:00:00.328
0:b7c 0 days 0:00:00.171
25:3f8 0 days 0:00:00.000
23:1968 0 days 0:00:00.000
thread 18 and 19 have been hanging around awhile.. hmm.... are they stuck in a loop?
~18s <-- goto thread 18.
!clrstack <-- clr call stack .. which is just like debugging in windows.
.. and from here u can dump objects and stuff by giving the address references and stuff.
check out !help to list some commands to try and use .. i think !help.sos also works?
HTH .. if u still get stuck, ask away at what worked and what didn't.
I just had to deal with a similar problem. In my case, it turned out that WinDbg wasn't able to find the correct version of mscorwks.dll. In addition to the Framework version, there is also a revision of the DLL which can be different between the same framework version.
In theory, the Microsoft symbol servers should be able to supply the necessary DLL, but it wasn't happening for me. To solve it, I used !sym noisy to get additional information on symbol loading. When I did !dumpstack, I got the error message:
SYMSRV: http://msdl.microsoft.com/download/symbols/mscorwks.dll/492B82C1590000/mscorwks.dll not found
To fix this, I created the appropriate folders in my local symbol cache, and copied mscorwks.dll from the machine the dump came from. After a .reload, WinDbg found the necessary DLL in the local symbol cache, and continued on happily.
Alternatively, you can find the exact version of mscorwks being used with lm v m mscorwks. You can then find the update that contains the version you need from this list. You will need to extract the necessary DLLs from the particular update to the right location.

Resources