I have implemented Spock Integration test TestControllerIntegrationSpec on Grails, Groovy,GROM and Mongodb environment and the Test case has been passed when only one Interation test class available in my development environment.But fails when development environment has more than one Integration test
Ran the test case "gradle clean integrationTest"
This Dispatcher has been shut down.;
nested exception is java.lang.IllegalArgumentException: This Dispatcher has been shut down.
org.springframework.transaction.CannotCreateTransactionException: This Dispatcher has been shut down.; nested exception is java.lang.IllegalArgumentException: This Dispatcher has been shut down.
at org.grails.transaction.ChainedTransactionManager.getTransaction(ChainedTransactionManager.java:127)
at org.grails.transaction.ChainedTransactionManager.getTransaction(ChainedTransactionManager.java:55)
at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:130)
at grails.transaction.GrailsTransactionTemplate.execute(GrailsTransactionTemplate.groovy:93)
at com.TestControllerIntegrationSpec.setup(TestControllerIntegrationSpec.groovy)
Caused by: java.lang.IllegalArgumentException: This Dispatcher has been shut down.
at reactor.core.support.Assert.isTrue(Assert.java:61)
at reactor.core.dispatch.AbstractLifecycleDispatcher.dispatch(AbstractLifecycleDispatcher.java:111)
at reactor.bus.EventBus.notify(EventBus.java:368)
at grails.events.Events$Trait$Helper.notify(Events.groovy:111)
at org.grails.events.spring.SpringEventTranslator.onApplicationEvent(SpringEventTranslator.groovy:66)
at org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:166)
at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:138)
at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:382)
at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:336)
at org.grails.datastore.gorm.events.ConfigurableApplicationContextEventPublisher.publishEvent(ConfigurableApplicationContextEventPublisher.groovy:30)
at org.grails.datastore.mapping.core.AbstractDatastore.publishSessionCreationEvent(AbstractDatastore.java:125)
at org.grails.datastore.mapping.core.AbstractDatastore.connect(AbstractDatastore.java:118)
at org.grails.datastore.mapping.core.AbstractDatastore.connect(AbstractDatastore.java:113)
at org.grails.datastore.mapping.transactions.DatastoreTransactionManager.doGetTransaction(DatastoreTransactionManager.java:101)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:337)
at org.grails.transaction.MultiTransactionStatus.registerTransactionManager(MultiTransactionStatus.java:68)
at org.grails.transaction.ChainedTransactionManager.getTransaction(ChainedTransactionManager.java:106)
... 4 more
Related
I'm using geoserver-2.20.3.war together with Apache Tomcat/9.0.36 on Linux. Everything works as it should but if i try to access the server status via the web administration interface i only get Error messages. I can't really figure out the problem and how to fix it.
`HTTP Status 500 – Internal Server Error
Type Exception Report
Message Handler dispatch failed; nested exception is java.lang.InternalError: java.lang.reflect.InvocationTargetException
Beschreibung The server encountered an unexpected condition that prevented it from fulfilling the request.
Exception
org.springframework.web.util.NestedServletException: Handler dispatch failed; nested exception is java.lang.InternalError: java.lang.reflect.InvocationTargetException
...
Root Cause
java.lang.InternalError: java.lang.reflect.InvocationTargetException
...
Root Cause
java.lang.reflect.InvocationTargetException
...
Root Cause
java.lang.NullPointerException
java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1262)
java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:225)
java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:107)
java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:719)
...
I tried to find a similar issue but unfortunately did not stumble over something really helpful.
I found a solution! The problem were missing fonts. After following these very helpful steps by Andreas Ahlenstorf and installing the font-package dejavu-fonts on linux everything works fine.
I work on quite a few services with similar architectures, with small differences. They all use Java 8, Maven, SpringBoot, and Jersey.
I normally debug them in Eclipse (currently on 2021-06) using "Run As->SpringBoot". This works perfectly fine. I can also run them from a command line using "mvn spring-boot:run", but that's just an academic exercise, because I prefer to run them from Eclipse.
When I run it from mvn, it successfully starts up, and I can hit listener endpoints (test case is actuator/info right now) with no problem.
When I run it from Eclipse, I get the following mystifying error:
BeanCreationException: Error creating bean with name 'mbeanExporter' defined in class path resource [org/springframework/boot/autoconfigure/jmx/JmxAutoConfiguration.class]: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.springframework.jmx.export.annotation.AnnotationMBeanExporter]: Factory method 'mbeanExporter' threw exception; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'mbeanServer' defined in class path resource [org/springframework/boot/autoconfigure/jmx/JmxAutoConfiguration.class]: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [javax.management.MBeanServer]: Factory method 'mbeanServer' threw exception; nested exception is org.springframework.jmx.MBeanServerNotFoundException: Could not access WebSphere's AdminServiceFactory.getMBeanFactory/getMBeanServer method; nested exception is java.lang.NullPointerException
Notice the last couple of phrases in that.
This service uses an ejb client class that is configured to connect to Websphere EJBs. One side effect of this is that jmx is not available. I have to set "spring.jmx.enabled=false".
Note that I went to the trouble of storing the log file for both runs, and I painstakingly compared them, verifying that they were logging the same information (varying by timestamps). That stacktrace above is the first place where they truly vary.
Curiously, although the Eclipse run shows this error, and listeners do not respond, it doesn't terminate the startup attempt. The service just sits there, sort of brain-dead.
I'm sure what I've provided isn't enough information, but I'm not sure what else would be useful information.
In our Java application using Drools 6.5 final release, we use Disruptor to run the same rules by different user threads, each thread has its own dedicated Session object while all the sessions are created from a common KieBase. Dev/QA did not see the following error but in Production, we see the error: the object being inserted is LinkedHashMap instance and this object will definitely being processed by one user thread (based on hashCode of immutable object coming with the message), so this is strange that this LinkedHashCode object would be modified by thread other than the user threads. Any thoughts on what could be the cause?
07:04:15.719 ERROR [RuleHandler6] erf.SupportsProfilingHandlerBase - Exception -
java.util.ConcurrentModificationException
at java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:711)
at java.util.LinkedHashMap$LinkedEntryIterator.next(LinkedHashMap.java:744)
at java.util.LinkedHashMap$LinkedEntryIterator.next(LinkedHashMap.java:742)
at java.util.AbstractMap.hashCode(AbstractMap.java:507)
at org.drools.core.common.EqualityAssertMapComparator.hashCodeOf(EqualityAssertMapComparator.java:46)
at org.drools.core.util.ObjectHashMap.get(ObjectHashMap.java:90)
at org.drools.core.common.ClassAwareObjectStore.getHandleForObject(ClassAwareObjectStore.java:150)
at org.drools.core.common.NamedEntryPoint.getFactHandle(NamedEntryPoint.java:680)
at consolidator.services.DroolsKieContainer$SessionWrapper.internalFire(DroolsKieContainer.java:198)
at consolidator.services.DroolsKieContainer$SessionWrapper.fire(DroolsKieContainer.java:175)
at consolidator.services.DroolsKieService.fire(DroolsKieService.java:153)
at consolidator.disruptor.RuleHandler.handleFIX(RuleHandler.java:88)
at consolidator.disruptor.RuleHandler.onEventCore(RuleHandler.java:68)
at consolidator.disruptor.RuleHandler.onEventCore(RuleHandler.java:15)
at consolidator.perf.SupportsProfilingHandlerBase.onEvent(SupportsProfilingHandlerBase.java:43)
at consolidator.perf.SupportsProfilingHandlerBase.onEvent(SupportsProfilingHandlerBase.java:9)
at com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:129)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
I am trying to deploy a JSF portlet into a Liferay portal 6.2 running on top of a JBoss EAP 6.4, with OpenJDK 8. The portlet is deployed as a WAR file, but invokes some methods of an EJB through a remote interface. The EJB is deployed as an EAR file directly on JBoss.
On my developing machine it is working fine. But in a test machine it is not. There are exactly the same WAR and EAR files, the standalone.xml setup is almost the same for both machines, and also the JBoss modules are the same.
The stacktrace printed in the log is the following:
JBWEB000236: Servlet.service() for servlet Adminis Servlet threw exception: javax.portlet.faces.BridgeException: javax.faces.FacesException
at com.liferay.faces.bridge.BridgePhaseRenderImpl.execute(BridgePhaseRenderImpl.java:91) [liferay-faces-bridge-impl-3.2.4-ga5.jar:3.2.4-ga5 (Ephesus / Feb 15, 2014 AD)]
at com.liferay.faces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:112) [liferay-faces-bridge-impl-3.2.4-ga5.jar:3.2.4-ga5 (Ephesus / Feb 15, 2014 AD)]
...
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_121]
Caused by: javax.faces.FacesException
at com.sun.faces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:139) [jsf-impl-2.1.28.redhat-8.jar:2.1.28.redhat-8]
at org.icefaces.impl.application.ExtendedExceptionHandler.handle(ExtendedExceptionHandler.java:113) [icefaces-3.3.0.jar:]
... 194 more
Caused by: java.util.NoSuchElementException
at java.util.HashMap$HashIterator.nextNode(HashMap.java:1439) [rt.jar:1.8.0_121]
at java.util.HashMap$KeyIterator.next(HashMap.java:1461) [rt.jar:1.8.0_121]
at org.jboss.ejb.client.EJBClientContext.getEJBReceiver(EJBClientContext.java:725) [jboss-ejb-client-1.0.30.Final-redhat-1.jar:1.0.30.Final-redhat-1]
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146) [jboss-ejb-client-1.0.30.Final-redhat-1.jar:1.0.30.Final-redhat-1]
...
at com.sun.proxy.$Proxy459.obtenerUsuarioPorCodigo(Unknown Source)
at com.sofis.adminis.delegates.PermisosDelegate.obtenerUsuarioPorCodigo(PermisosDelegate.java:450) [adminis-delegate-1.0.jar:]
at com.sofis.security.web.UsuariosSessionBeanWeb.autenticar(UsuariosSessionBeanWeb.java:1927) [classes:]
at com.sofis.security.web.listeners.SofisAutologinLiferayPhaseListener.afterPhase(SofisAutologinLiferayPhaseListener.java:54) [classes:]
at com.sun.faces.lifecycle.Phase.handleAfterPhase(Phase.java:189) [jsf-impl-2.1.28.redhat-8.jar:2.1.28.redhat-8]
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:107) [jsf-impl-2.1.28.redhat-8.jar:2.1.28.redhat-8]
... 198 more
I rised the log level to "org.jboss.ejb.client" and now I see two interesting messages just before the stactrace:
22:13:16,684 DEBUG [org.jboss.ejb.client.EJBClientContext] (ajp-/0.0.0.0:8009-5) org.jboss.as.ejb3.remote.LocalEJBReceiverPreferringDeploymentNodeSelector#4bc9113e deployment node selector selected node for appname=SS-ADMINIS-ear-1.0,modulename=SS-ADMINIS-MAVEN-EJB-1.0,distinctname=
22:13:16,687 DEBUG [org.jboss.ejb.client.EJBClientContext] (ajp-/0.0.0.0:8009-5) Selected node doesn't belong to eligible receivers. Continuing with a random eligible receiver
Note that there is no node name in both messages (two blanks before "node").
In my developing machine, where it works, the first message does include a node name, and the second message does not appear:
18:56:37,902 DEBUG [org.jboss.ejb.client.EJBClientContext] (http-/0.0.0.0:8080-2) org.jboss.as.ejb3.remote.LocalEJBReceiverPreferringDeploymentNodeSelector#6db73304 deployment node selector selected spio node for appname=SS-ADMINIS-ear-1.0,modulename=SS-ADMINIS-MAVEN-EJB-1.0,distinctname=
The only diference is that in my machine I am going directly with the browser to the server ([Browser] -- HTTP --> [JBoss]) while in the testing machine I go through a load balancer ([Browser] -- HTTP --> [Apache] -- AJP --> [JBoss]). That is reflected in the messages (ajp-/0.0.0.0 vs http-/0.0.0.0).
The exception is thrown when I try to invoke a method from the EJB through the remote interface. The reference to the local stub is gotten by means of a lookup, and the result is not null. There are no errors at deploy and the lookup does not throw an error neither.
What can be happening or what am I missing?
A friend of mine found the solution.
Something a did't say is that the testing machine was in fact a docker container. And it seems that there is a bug in JBoss with docker making the former to not read the hostname to pick a node name, so de node name when it starts is empty. So the message above a empty name node being selected is shown, and then the error.
The workaround is to specify a node name with the -Djboss.node.name parameter to JBoss. I put that setting in the standalone.conf, restarted the JBoss and it worked fine. Now, the first message shows the name I specified, and the second message does not appear, nor the exception.
I am facing an issue with SBT (version 0.13.9). One of my ScalaTest tests fails not deterministic with EOFException.
Stack trace:
Exception in thread "Thread-155" Exception in thread "Thread-159" java.io.EOFException
at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2601)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1319)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:371)
at sbt.React.react(ForkTests.scala:114)
at sbt.ForkTests$$anonfun$mainTestTask$1$Acceptor$2$.run(ForkTests.scala:74)
at java.lang.Thread.run(Thread.java:745)
java.io.EOFException
at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2601)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1319)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:371)
at org.scalatest.tools.Framework$ScalaTestRunner$Skeleton$1$React.react(Framework.scala:953)
at org.scalatest.tools.Framework$ScalaTestRunner$Skeleton$1.run(Framework.scala:942)
at java.lang.Thread.run(Thread.java:745)
sbt.ForkMain 59974 failed with exit code 134
I don't see any JVM logs or thread dumps.
Almost certainly this is related to the Java classpath being too long when invoking sbt.ForkMain in certain linux distros. To avoid this I added
javaOptions in Test ++= Seq("-Xms1G","-XX:+CMSClassUnloadingEnabled","-XX:+UseConcMarkSweepGC")
to the build.sbt file. I reckon CMSClassUnloadingEnabled is where the magic happens.
SBT single thread or multi threaded tests forks the JVM and if the host name is not resolved it just fails with this error message. If you look at the logs in the tests, you might see
Uncaught exception when running tests: java.net.ConnectException: Operation timed out
So the easy way to resolve this is to add your hostname to the /etc/hosts and map it to localhost something like this
::1 localhost blahblah
This should resolve the issue.