-
Bug
-
Resolution: Not an issue
-
Blocker
-
None
-
4.5.11, 4.5.12, 5.2
-
Mac OS X 10.8.5
JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build 1.7.0_45-b18)
Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode bsd-amd64 compressed oops)
An EE customer was experiencing tons of "lost network connections" (images, css or even on webpages) and frequent core dumps on their development machines. We first thought this would be due to something specific in their setup, but then had to realize that this can be reliably reproduced even with a plain vanilla Magnolia CE bundled web app.
To be absolutely sure that the problem was not due to incompetence in the build or setup I painstakingly followed Greg's instructions on his blog (http://dev.magnolia-cms.com/~gjoseph/dont-build-magnolia-build-your-projects):
First, I created the project with the archetype:
%> mvn archetype:generate -DarchetypeCatalog=http://nexus.magnolia-cms.com/content/groups/public/ Choose version: 1: 1.1.0 2: 1.2.0-SNAPSHOT Choose a number: 2: 1 Define value for property 'groupId': : com.acme Define value for property 'artifactId': : acme-project Define value for property 'version': 1.0-SNAPSHOT: : Define value for property 'package': com.acme: : Define value for property 'magnolia-version': : 4.5.12 Define value for property 'project-name': acme-project: : My ACME Project Confirm properties configuration: groupId: com.acme artifactId: acme-project version: 1.0-SNAPSHOT package: com.acme magnolia-version: 4.5.12 project-name: My ACME Project Y: :
Project was created and could be built fine. Then I ran it in Tomcat 7.0.35 (also tried TC 6 with the same results, customer even tried on TC 8). Magnolia started up and installed fine - no problems.
Then we converted it to a bundled web app by changing the dependencies to magnolia-bundled-webapp in the parent pom and the web app pom. The project still built successfully built, but when trying to launch it, I got a ModuleDependencyException:
Module Magnolia RSS Aggregator Module (version 1.4.3) is dependent on scheduler version 1.5.5/*, but Magnolia Scheduler Module (version 1.5.2) is currently installed.
Alright, so somebody did not test this before releasing it. But that's a different story (or "issue"). I added the scheduler module to the dependency management in the parent pom and did a new clean build and install. Now the installer could be loaded. However when launching the installation...
- first few steps run o.k.,
- then "network connection lost" errors started to show up in the browser console (and images got lost)
- then a core was printed to the log:
# # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00000001047fba20, pid=19833, tid=54787 # # JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build 1.7.0_45-b18) # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode bsd-amd64 compressed oops) # Problematic frame: # C [libjava.dylib+0x9a20] JNU_NewStringPlatform+0x1c8 # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /Users/will/Documents/Work/Java/Tomcat/apache-tomcat-7.0.35/hs_err_pid19833.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. #
Sometimes the JVM crashes quickly, sometime the installation process hangs and the JVM crashes with a lag. And it seems the problem start to appear when Magnolia is bootstrapping stuff.
This did never happen as long as I was using Java 1.6. And it does not happen when using magnolia-empty-webapp.
- is related to
-
MAGNOLIA-5526 Prevent installation on problematic environments
-
- Closed
-
- mentioned in
-
Page Loading...
-
-
-
-
-
-
-
-
-
-
-
