failed: javax.persistence.PersistenceException: The default EbeanServer has not been defined? This is normally set via the ebean.datasource.default property. Otherwise it should be registered programatically via registerServer(), took 0.393 sec
[error] at com.avaje.ebean.Ebean$ServerManager.getPrimaryServer(Ebean.java:178)
[error] at com.avaje.ebean.Ebean$ServerManager.access$300(Ebean.java:128)
[error] at com.avaje.ebean.Ebean.createSqlQuery(Ebean.java:785)
[error] at models.Amplify.getHierarchy(Amplify.java:42)
[error] at services.AmplifyNodeServiceImplTest.shouldGetAmplifyNodeInfo(AmplifyNodeServiceImplTest.java:43)
when running the JUnit test cases,i am facing the above exception.
You have to extend the play.test.WithServer class. For example:
public class SomeModelTest extends WithServer {
// Your testing code that uses Ebean
}
The WithServer class ensures the server is properly initialized (databases, EbeanServer, etc.)
Related
Ok, I don't rly know where to start, but let's do this.
So for two weeks I had my last working day where everything was working fine in VS 2019 (16.11.4). Today I wanted to start a project, and i got the following error message:
Unfortunately, a process used by VS has encountered an unrecoverable error.
Stack Trace:
Microsoft.ServiceHub.Client.ControllerConnectionException : Controller terminated before accepting connections. Exit code: -1073741674.
at async Microsoft.ServiceHub.Client.HubControllerClient.StartAsync(<Unknown Parameters>)
at async Microsoft.ServiceHub.Client.HubClient.LaunchOrFindControllerAsync(<Unknown Parameters>)
at async Microsoft.ServiceHub.Client.HubClient.GetLocationServiceAsync(<Unknown Parameters>)
at async Microsoft.ServiceHub.Utility.Shared.ServiceHubRetry.ExecuteAsync[TReturnType](<Unknown Parameters>)
at async Microsoft.ServiceHub.Utility.Shared.ServiceHubRetry.ExecuteAsync[TReturnType](<Unknown Parameters>)
at async Microsoft.ServiceHub.Client.HubClient.GetThisAsRemoteServiceBrokerAsync(<Unknown Parameters>)
at async Microsoft.ServiceHub.Client.HubClient.<Reset>b__54_0(<Unknown Parameters>)
at async Microsoft.VisualStudio.Threading.AsyncLazy`1.<>c__DisplayClass13_0.<GetValueAsync>b__0[T](<Unknown Parameters>)
at async Microsoft.ServiceHub.Client.HubClient.GetPipeAsync(<Unknown Parameters>)
at async Microsoft.ServiceHub.Client.HubClient.RequestServiceAsync(<Unknown Parameters>)
at async Microsoft.CodeAnalysis.Remote.ServiceHubRemoteHostClient.RequestServiceAsync(<Unknown Parameters>)
at Microsoft.VisualStudio.Telemetry.WindowsErrorReporting.WatsonReport.GetClrWatsonExceptionInfo(Exception exceptionObject)
Followed by another error:
There was an error activating the remote language server. Plese select Help > Send Feedback > Report a problem.
These errors also appear, when I create a new project. The only way I can start VS19 without errors is, when I click "Continue without code" in the popup.
So I tried to repair or modify VS. When I want to repair it, it failed. The popup which is prepairing the repair info is shutting down with no error message.
I didn't find that much information in the internet, especially with the error code.
Furthermore I detected, that I cannot install or uninstall VS19. Plus, I cannot install VS22, because it is aborting again after the "preparing the VS installer". Again no error is poping up.
A sample log:
[2cf4:0001][2021-12-15T17:45:47] Saving the current locale (de-DE) to user.json.
[2cf4:0001][2021-12-15T17:45:47] Setting the telemetry services
[2cf4:0004][2021-12-15T17:45:47] Creating a new telemetry service.
[2cf4:0001][2021-12-15T17:45:47] Visual Studio Installer Version: 3.0.4496
[2cf4:0001][2021-12-15T17:45:47] Raw Command line: "C:\Program Files (x86)\Microsoft Visual Studio\Installer\setup.exe"
[2cf4:0001][2021-12-15T17:45:47] Using registry value of (1) to theme installer.
[2cf4:0001][2021-12-15T17:45:47] Getting singleton lock. Mutex name: DevdivInstallerUI
[2cf4:0004][2021-12-15T17:45:47] Telemetry session ID: ...
[2cf4:0001][2021-12-15T17:45:47] Getting singleton lock succeed.
[2cf4:0006][2021-12-15T17:45:47] Creating new ExperimentationService
[2cf4:0006][2021-12-15T17:45:47] Telemetry property VS.ABExp.Flights : lazytoolboxinit;fwlargebuffer;refactoring;spmoretempsbtn1;asloff;keybindgoldbarext;asynccsproj;vsfricheditor;completionapi;tn-vsmacnps-7;toggleblockcomment;tasmigddvs;multitenanttasmigration_002;vsfdevcom2;lsprmsgvol;debugger-init-asynccf;vswnewinstaller;links_carousel_tfl;azure_links_tf
**[2cf4:0003][2021-12-15T17:45:47] An abnormal shutdown was detected from the previous telemetry session.**
[2cf4:0004][2021-12-15T17:45:47] Telemetry property vs.willow.source : WPF
[2cf4:0004][2021-12-15T17:45:47] Telemetry property vs.willow.locale : de-DE
[2cf4:0004][2021-12-15T17:45:47] Telemetry property vs.willow.installerversion : 3.0.4496.34889
[2cf4:0004][2021-12-15T17:45:47] Telemetry property vs.willow.startmethod : direct
[2cf4:0004][2021-12-15T17:45:47] Telemetry property vs.willow.activityid : ...
[2cf4:0004][2021-12-15T17:45:47] Telemetry property vs.willow.campaign : 70
[2cf4:0004][2021-12-15T17:45:47] Telemetry property vs.willow.passive : False
[2cf4:0004][2021-12-15T17:45:47] Telemetry property vs.willow.quiet : False
[2cf4:0004][2021-12-15T17:45:47] Telemetry property vs.willow.processtype : ui
[2cf4:0001][2021-12-15T17:45:47] Monitor center position: 960, 585
[2cf4:0001][2021-12-15T17:45:47] Showing the window.
I didn't really know what Telemetry was for. Can this cause any issues due to fireall/network problems, that I cannot install, repair, uninstall VS?
With sfc /scannow I got following lines:
2021-12-16 16:25:52, Info CSI 00000293 [SR] Cannot repair member file [l:15]'mscorlib.ni.dll' of NetFx4-mscorlib_ni, version 4.0.15805.350, arch amd64, versionScope neutral, pkt {l:8 b:b03f5f7f11d50a3a} in the store, hash mismatch
2021-12-16 16:25:52, Info CSI 00000294 [SR] This component was referenced by [l:78]'Package_3_for_KB5004331~31bf3856ad364e35~amd64~~10.0.4400.1.5004331-51_neutral'
2021-12-16 16:25:52, Info CSI 00000295 Hashes for file member [l:15]'mscorlib.ni.dll' do not match.
2021-12-16 16:25:52, Info CSI 00000297 [SR] Could not reproject corrupted file \??\C:\Windows\Microsoft.NET\Framework64\v4.0.30319\NativeImages\\mscorlib.ni.dll; source file in store is also corrupted
Does this have any connection to my general problem?
Maybe(!) a very similar problem, this guy was facing:
https://developercommunity.visualstudio.com/t/visual-studio-installer-vs2019-keep-crashing-sudde/711824
So... (further) things I tried:
Installed .NET Frameworks again
Tried the reapair tools for VS and .NET
Tried to repair VS19, but I cant
Run sfc scannow
Run chkdsk scan
Several reboots, restarting VS, ...
I am trying to connect an application with VisualVM, but VisualVM unable to connect with application: Below is the env:
JBoss EAP 7.3
Java 11
OpenShift
I have tried to configure it in different ways, but all failed:
Config try 1:
Use few env variables in script file, so that it could execute first (file contents are mentioned below):
echo *** Adding system property for VisulVM ***
batch
/system-property=jboss.modules.system.pkgs:add(value="org.jboss.byteman,com.manageengine,org.jboss.logmanager")
/system-property=java.util.logging.manager:add(value="org.jboss.logmanager.LogManager")
run-batch
I can see that above commands executed successfully and above properties are available in JBoss config (I verified using Jboss cli command).
JAVA_TOOLS_OPTIONS: -agentlib:jdwp=transport=dt_socket,server=y,address=8000,suspend=n -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.rmi.port=3001 -Djava.rmi.server.hostname=127.0.0.1 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Xbootclasspath/a:/opt/eap/modules/system/layers/base/org/jboss/log4j/logmanager/main/log4j-jboss-logmanager-1.2.0.Final-redhat-00001.jar -Xbootclasspath/a:/opt/eap/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-2.1.14.Final-redhat-00001.jar
Result:
- java.lang.RuntimeException: WFLYCTL0079: Failed initializing module org.jboss.as.logging
- Caused by: java.util.concurrent.ExecutionException: java.lang.IllegalStateException: WFLYLOG0078: The logging subsystem requires the log manager to be org.jboss.logmanager.LogManager. The subsystem has not be initialized and cannot be used. To use JBoss Log Manager you must add the system property "java.util.logging.manager" and set it to "org.jboss.logmanager.LogManager"
Config 2:
JAVA_TOOL_OPTIONS= -agentlib:jdwp=transport=dt_socket,server=y,address=8000,suspend=n -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.rmi.port=3001 -Djava.rmi.server.hostname=127.0.0.1 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.util.logging.manager=org.jboss.logmanager.LogManager -Djboss.modules.system.pkgs=org.jboss.byteman,org.jboss.logmanager -Xbootclasspath/a:/opt/eap/modules/system/layers/base/org/jboss/log4j/logmanager/main/log4j-jboss-logmanager-1.2.0.Final-redhat-00001.jar -Xbootclasspath/a:/opt/eap/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-2.1.14.Final-redhat-00001.jar
Result:
WARNING: Failed to instantiate LoggerFinder provider; Using default.
java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
Config 3:
• Modify in standalone.conf, where I put all required configuration in this file.
Result:
WARNING: Failed to instantiate LoggerFinder provider; Using default.
java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
Kindly suggest that what is the correct configurations?
I am following the developer guide to deploy SCDF to a minikube cluster on my local machine. Used the helm chart approach. Was able to get it working with the defaults. The default deploys a mariadb in the cluster. I wanted to change it to use an external mysql db that is running in a docker container in my machine (outside the cluster). Followed the recommendations to change the values.yaml to enable the external DB and attributes for external DB connection (URI, dbname, user/pwd etc.).
Then deployed using "helm install my-release -f values.yaml bitnami/spring-cloud-dataflow"
The SCDF pod (& skipper pod) errors out because it can't find the mysql jdbc driver. kubectl logs on the pods show the following error: "java.lang.IllegalStateException: Cannot load driver class: com.mysql.cj.jdbc.Driver"
How do I include the mysql jdbc driver in the image for SCDF that gets deployed (or resolve this problem). I read SCDF already includes the drivers for std databases (true ?). New to helm/k8s so apologies if solution is obvious... Other posts on similar error all talk about including this in the pom.xml . But this is not a dependency issue with my (task) app but SCDF itself.
thanks
-------------------- more detail on the exception stack ---------------
Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'dataSource' defined in class path resource [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [com.zaxxer.hikari.HikariDataSource]: Factory method 'dataSource' threw exception; nested exception is java.lang.IllegalStateException: Cannot load driver class: com.mysql.cj.jdbc.Driver
at org.springframework.beans.factory.support.ConstructorResolver.instantiate(ConstructorResolver.java:657)
...
Looks like I just need to specify the mariadb jdbc driver in the values.yaml file for mysql as well. That got past the load class error.
But still would like to know how to prevent class load error for a different driver specified when SCDF is deployed to k8s via the helm chart.
I'm compiling some very large projects in chisel3 with lots of wires and connections. Right now, the top level object and all of its submodules are in the same Scala package, and I run sbt "runMain top.Instantiator --verilog". However, it crashes in FIRRTL with:
[info] Done packaging.
[info] Running top.Instantiator --verilog --testArgs vcs
[info] [0.005] Elaborating design...
[info] [68.146] Done elaborating.
[error] (run-main-0) java.lang.NegativeArraySizeException
[error] java.lang.NegativeArraySizeException
[error] at java.util.Arrays.copyOf(Arrays.java:3332)
[error] at org.antlr.v4.runtime.ANTLRInputStream.load(ANTLRInputStream.java:101)
[error] at org.antlr.v4.runtime.ANTLRInputStream.<init>(ANTLRInputStream.java:64)
[error] at org.antlr.v4.runtime.ANTLRInputStream.<init>(ANTLRInputStream.java:60)
[error] at org.antlr.v4.runtime.ANTLRInputStream.<init>(ANTLRInputStream.java:68)
[error] at firrtl.Parser$$anonfun$1.apply(Parser.scala:35)
[error] at firrtl.Parser$$anonfun$1.apply(Parser.scala:29)
[error] at firrtl.Utils$.time(Utils.scala:135)
[error] at firrtl.Parser$.parse(Parser.scala:29)
[error] at firrtl.Driver$$anonfun$execute$1.apply(Driver.scala:171)
[error] at firrtl.Driver$$anonfun$execute$1.apply(Driver.scala:140)
[error] at logger.Logger$$anonfun$makeScope$1.apply(Logger.scala:129)
[error] at scala.util.DynamicVariable.withValue(DynamicVariable.scala:58)
[error] at logger.Logger$.makeScope(Logger.scala:127)
[error] at firrtl.Driver$.execute(Driver.scala:140)
[error] at chisel3.Driver$.execute(Driver.scala:180)
[error] at chisel3.Driver$.execute(Driver.scala:200)
[error] at fringe.CommonMain$class.main(CommonMain.scala:64)
[error] at top.Instantiator$.main(Instantiator.scala:17)
[error] at top.Instantiator.main(Instantiator.scala)
[error] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[error] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[error] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[error] at java.lang.reflect.Method.invoke(Method.java:498)
[error] Nonzero exit code: 1
[error] (Compile / runMain) Nonzero exit code: 1
My guess is that the huge number of wires and connections in the project are causing some overflow. Does anyone have experience with this kind of error and advice on how to go about debugging it? Right now, my ideas are to
1) refactor the chisel code to make it easier to compile
2) figure out a way to generate verilog for each module separately and then link them together at the end. Is there a way to compile non-recursively so I don't run into the same error when I get to compiling top.Instantiator?
3) separate the packages/projects somehow so that sbt works on each one separately
Thanks
Adding idea 4) Use protobuf serialization between chisel and firrtl.
I can see that firrtl is blowing up in the parser. The protobuf support is fairly new, but I believe it is much less memory intensive than the antlr based parser.
Here's an example of producing a firrtl protobuf serialization from chisel3
import chisel3._
class XX extends Module {
val io = IO(new Bundle {
val i = Input(UInt(1.W))
val o = Output(UInt(1.W))
})
io.o := io.i
}
object PB {
def main(args: Array[String]): Unit = {
val c = Driver.elaborate(() => new XX)
Driver.dumpProto(c, None)
}
}
You can then generate the verilog with the firrtl compiler
firrtl -i XX.pb -X verilog -o XX.v
Or build your own compiler something like
import firrtl._
object PB {
def main(args: Array[String]): Unit = {
Driver.execute(Array("-i", "XX.pb", "-X", "verilog", "-o", "XX.v"))
}
}
Your other options may be worth pursuing but this might be an easier quick fix.
My integration tests are failing when I run them from a Gradle task.
org.springframework.data.solr.UncategorizedSolrException: **SolrCore 'collection1' is not available due to init failure: Error opening new searcher; nested exception is org.apache.solr.common.SolrException: SolrCore 'collection1' is not available due to init failure: Error opening new searcher**
at org.springframework.data.solr.core.SolrTemplate.execute(SolrTemplate.java:122)
at org.springframework.data.solr.core.SolrTemplate.saveDocuments(SolrTemplate.java:206)
at org.springframework.data.solr.core.SolrTemplate.saveDocuments(SolrTemplate.java:201)
org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: NativeFSLock#/opt/solr/example/solr/collection1/data/index/write.lock
When I run the integration tests directly in Intellij, the tests run successfully. Here is my bean definition for the embedded server. I added the destroyMethod and it had no effect.
#Bean(destroyMethod = "shutdown")
public SolrServer solrServer(org.apache.commons.configuration.Configuration configuration) {
EmbeddedSolrServerFactory factory;
try {
factory = new EmbeddedSolrServerFactory(configuration.getString("solr.home"));
} catch (ParserConfigurationException | IOException | SAXException e) {
String errorMsg = "Encountered an exception while initializing the SolrServer bean.";
log.error(errorMsg, e);
throw new OrdersClientRuntimeException(errorMsg, e);
}
return factory.getSolrServer();
}
Here are the logs. Everything seems to be shutting down correctly.
2014-09-02 17:32:15.757 thread="Thread-6" level="DEBUG" logger="o.s.b.f.s.DisposableBeanAdapter" - **Invoking destroy method 'shutdown' on bean with name 'solrServer'**
2014-09-02 17:32:15.759 thread="Thread-8" level="DEBUG" logger="o.s.b.f.s.DefaultListableBeanFactory" - Retrieved dependent beans for bean 'solrDocumentRepository': [net.nike.orders.client.search.repository.DocumentRepositorySpec]
2014-09-02 17:32:15.759 thread="Thread-6" level="INFO " logger="org.apache.solr.core.CoreContainer" - **Shutting down CoreContainer instance=179265569**
2014-09-02 17:32:15.760 thread="Thread-8" level="DEBUG" logger="o.s.b.f.s.DisposableBeanAdapter" - **Invoking destroy method 'shutdown' on bean with name 'solrServer'**
2014-09-02 17:32:15.760 thread="Thread-8" level="INFO " logger="org.apache.solr.core.CoreContainer" - **Shutting down CoreContainer instance=1604485329**
2014-09-02 17:32:15.762 thread="Thread-6" level="INFO " logger="org.apache.solr.core.SolrCore" - [collection1] **CLOSING SolrCore** org.apache.solr.core.SolrCore#28da98e2
2014-09-02 17:32:15.769 thread="Thread-8" level="DEBUG" logger="o.a.h.i.c.PoolingClientConnectionManager" - **Connection manager is shutting down**
2014-09-02 17:32:15.769 thread="Thread-6" level="INFO " logger="**org.apache.solr.update.UpdateHandler" - closing** DirectUpdateHandler2{commits=23,autocommit maxTime=15000ms,autocommits=0,soft autocommits=2,optimizes=0,rollbacks=0,expungeDeletes=0,docsPending=0,adds=0,deletesById=0,deletesByQuery=0,errors=0,cumulative_adds=33,cumulative_deletesById=32,cumulative_deletesByQuery=0,cumulative_errors=0,transaction_logs_total_size=5302,transaction_logs_total_number=10}
2014-09-02 17:32:15.771 thread="Thread-8" level="DEBUG" logger="o.a.h.i.c.PoolingClientConnectionManager" - Connection manager shut down
2014-09-02 17:32:15.773 thread="Thread-8" level="DEBUG" logger="o.a.h.i.c.PoolingClientConnectionManager" - Connection manager is shutting down
2014-09-02 17:32:15.774 thread="Thread-8" level="DEBUG" logger="o.a.h.i.c.PoolingClientConnectionManager" - Connection manager shut down
Here is my environment information:
Linux Mint 17
Solr 4.9.0
Solr Test Framework 4.9.0
Oracle Java 1.7
Spring Data Solr 1.2.2.RELEASE
IntelliJ 13.1.4
Gradle 1.12
Tests are developed in Spock
Any help would be greatly appreciated. Thanks!
I ran into the same thing with my tests but the unlockOnStartup flag didn't work for me. I ended up changing the lock type (and leaving unlockOnStartup commented out):
<lockType>${solr.lock.type:single}</lockType>
<!--<unlockOnStartup>true</unlockOnStartup>-->
The note on the default lock type (native) makes me think that I don't the server shutting down cleany between test runs but I haven't been able to find it yet :(
native = NativeFSLockFactory - uses OS native file locking.
Do not use when multiple solr webapps in the same
JVM are attempting to share a single index.
Just had a similar issue and got it fixed.
I use the EmbeddedSolrServer in my unit tests and dynamically create new cores during runtime.
When creating the CoreContainer be sure to call shutdown() after the tests.
Also be sure all SolrCore instances are closed after your tests.
Calling coreContainer.create(CoreDescriptor, name, ...) opens a SolrCore which you have to close manually.
When creating the EmbeddedSolrServer by passing the coreName, the SolrCore is not opened! Open and close is handled by the EmbeddedSolrServer for each request/action.
Ok, so I was able to fix the issue by changing
<unlockOnStartup>true</unlockOnStartup>
in the solrconfig.xml file.