We have a play2.3.4 codebase with lots of specs2 tests. When I switch to 0.13.7-RC2 the tests suddenly don't run, they just hang.
sbt --debug gives the following output and then just stops (with cpu activity < 1%)
[debug] Framework implementation 'org.scalacheck.ScalaCheckFramework' not present.
[debug] Framework implementation 'org.specs.runner.SpecsFramework' not present.
[debug] Framework implementation 'org.scalatest.tools.Framework' not present.
[debug] Framework implementation 'org.scalatest.tools.ScalaTestFramework' not present.
[debug] Subclass fingerprints: List((junit.framework.TestCase,false,com.novocode.junit.JUnit3Fingerprint#99d898d), (org.specs2.specification.SpecificationStructure,true,specs2 Specification fingerprint), (org.specs2.specification.SpecificationStructure,false,specs2 Specification fingerprint), (org.specs2.runner.FilesRunner,true,specs2 Specification files fingerprint), (org.specs2.runner.FilesRunner,false,specs2 Specification files fingerprint))
[debug] Annotation fingerprints: List((org.junit.runner.RunWith,false,com.novocode.junit.RunWithFingerprint#4c7011c4), (org.junit.Test,false,com.novocode.junit.JUnitFingerprint#519e8210))
What is going on here? How can I troubleshoot this?
I ran jstack to see whether a thread was hanging and there was a test dependency downloading a big file. The testplugin didn't report any activity.
You can find the PID of the javaproces with jps.
Related
I am running dbt version 1.0.4 on Airflow. My ETL pipeline is running fine.
But I notice that dbt takes a long time to parse files every time it run on Airflow. Some lines in the log:
[2022-06-14 05:06:54,523] {subprocess.py:78} INFO - 05:06:54.506639 [debug] [MainThread]: Parsing macros/common/helpers/dropif.sql
[2022-06-14 05:06:55,826] {subprocess.py:78} INFO - 05:06:55.809703 [debug] [MainThread]: 1605: jinja rendering because of STATIC_PARSER flag. file: mart/domain_1/model_1.sql
Since my project is quite big, it takes a looooong time to actual run the query.
So, is there any way for me to bypass the parsing?
I add --no-static-parser. But I want to reduce more parsing time.
I am running a Gatling test script using Jenkins on a Unix machine. The test and the Simulation passes successfully after which I am seeing the below error marked in bold below also causing the Jenkins build to fail.
Log from the Jenkins build
Reports generated in 0s.
Please open the following file: >/var/lib/jenkins/workspace/gatling_test_job/target/gatling/demoscript-20200930173820423/index.html
[info] Simulation DemoScript successful.
[info] Simulation(s) execution ended.
[success] Total time: 326 s (05:26), completed Sep 30, 2020 5:43:32 PM
>[error] Expected ';'
[error] com.test.performance.DemoScript
[error] ^
Build step 'Build using sbt' changed build result to FAILURE
Build step 'Build using sbt' marked build as failure
I am using build using sbt block in my Jenkins job to trigger the test using the below command
gatling:testOnly com.test.performance.DemoScript
Scala Version is - 2.12.10
Gatling and related libraries - 3.3.1
Build using sbt config in Jenkins
sbt installation in global tool configuration
We've built a CordApp which connects with RabbitMQ and requires a configuration file to configure the subscribers and publishers to the message queues.
The CorDapp is build against 3.2-corda but fails to load the configuration file when running on a Corda Enterprise 3.2 node.
The following exception is appended to the logs when we start the Corda web server:
Starting as webserver: localhost:8080 [ERROR] 11:59:24+0000 [main]
messaging.XXX.initializeQueues - Exception caught when subscribing to
Rabbit queues [ERROR] 11:59:24+0000 [main]
messaging.XXX.initializeQueues -
net.corda.nodeapi.internal.config.ConfigUtilities.parseAs(Lcom/typesafe/config/Config;Lkotlin/reflect/KClass;)Ljava/lang/Object;
java.lang.NoSuchMethodError:
net.corda.nodeapi.internal.config.ConfigUtilities.parseAs(Lcom/typesafe/config/Config;Lkotlin/reflect/KClass;)Ljava/lang/Object;
Nov 27, 2018 11:59:25 AM
org.glassfish.jersey.internal.inject.Providers checkProviderRuntime
The code that loads the configuration is as follows:
val connectionConfig = defaultConfig!!
.resolve()
.getConfig("app-integration.rabbitMqConnectionConfiguration")
.parseAs<RabbitMqConnectionConfiguration>()
Given we are using a generic parseAs<RabbitMqConnectionConfiguration>() method, we assume that this is intended to subsequently call a parseAs(Config, KClass): Object method, but for some reason, it seems to be missing?
I would actually take a look at #joel's suggestion above. Corda is not an 'open core' project just yet.
So it's possible that you should compile the cordapps against the enterprise jar to determine whether the issue is the app or a different API between the two corda versions.
My other suspicion is that there might be different versions of java that are being used in the corda OS and the corda enterprise.
I would also see if this issue persists in the latest version of corda as well.
I have an SBT build for a project that requires Java 8 and I have also included some Java 8 features (mainly java.time package elements) in the build itself. If I attempt to build the project on an earlier JVM (such as 1.7), I get a whole load of errors and exceptions when I run the sbt command.
So, I decided to add an initialize property to detect the JVM in use and terminate the build with an elegant message if the JVM in use wasn't at least version 8. Of course, this only works if I use it to build the builder (if I put it in ./build.sbt, then I still get errors if using JVM 1.7 or earlier because the java.time elements are not present). So I have a ./project/build.sbt file that contains the following:
initialize := {
val _ = initialize.value
if (!scala.util.Properties.isJavaAtLeast ("1.8")) {
sys.error ("My project requires Java 8 or later")
}
}
This works, but rather inelegantly. If I run sbt with Java 7, then I get the following output from the build:
java.lang.RuntimeException: My project requires Java 8 or later
at scala.sys.package$.error(package.scala:27)
at $ed9be51e9ab4a59b3b3b$$anonfun$$sbtdef$1.apply(C:\Users\me\Documents\src\myproject\project\build.sbt:55)
at $ed9be51e9ab4a59b3b3b$$anonfun$$sbtdef$1.apply(C:\Users\me\Documents\src\myproject\project\build.sbt:47)
at scala.Function1$$anonfun$compose$1.apply(Function1.scala:47)
at sbt.EvaluateSettings$MixedNode.evaluate0(INode.scala:177)
at sbt.EvaluateSettings$INode.evaluate(INode.scala:135)
at sbt.EvaluateSettings$$anonfun$sbt$EvaluateSettings$$submitEvaluate$1.apply$mcV$sp(INode.scala:67)
at sbt.EvaluateSettings.sbt$EvaluateSettings$$run0(INode.scala:76)
at sbt.EvaluateSettings$$anon$3.run(INode.scala:72)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
[error] My project requires Java 8 or later
[error] Use 'last' for the full log.
Project loading failed: (r)etry, (q)uit, (l)ast, or (i)gnore?
If I place the same code in an empty ./build.sbt file, and run using Java 7 then I simply get:
[error] My project requires Java 8 or later
[error] Use 'last' for the full log.
Project loading failed: (r)etry, (q)uit, (l)ast, or (i)gnore?
That is, I don't get the exception message and stack trace.
Is there a way to make the build build exit more elegantly, so that I get output of the latter form rather than the former?
I am using the sbt-release plugin.
The process seems to work, however, sbt logs the final release step, pushChanges as error. Ideally, only actual errors are logged to error output as it can confuse the automation.
Sample output here:
Push changes to the remote repository (y/n)? [y] y
[error] To git#git.mycompany.com:gsilin/s3-client.git
[error] 67277ef..a1b959f my_branch -> my_branch
[error] To git#git.mycompany.com:gsilin/s3-client.git
[error] * [new tag] v0.1.8 -> v0.1.8
my_branch in this case is not the master branch (as I'm testing this process on my own branch before it goes to master), could that be the issue?
I don't know if something's changed in the latest version, but before sbt-release was warning you before this push step, that git sends it's info on stderr and so it will be shown with error messages in sbt although the process goes perfectly fine. So it's ok, don't worry.