Develop Reference

Tomcat 9 no longer starting using systemctl but will start manually

Been digging on this for a while. I reviewed multiple articles on this issue. This one was the closest:
Tomcat 8 on CentOS 7 does not start as service (but it starts manually ....)
The difference being that I am running Tomcat 9.0.33. Here are the particulars:
java version "1.8.0_121"\
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)\
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)\
Tomcat 9.0.33
NAME="CentOS Linux"\
VERSION="7 (Core)"\
ID="centos"\
ID_LIKE="rhel fedora"\
VERSION_ID="7"\
PRETTY_NAME="CentOS Linux 7 (Core)"\
ANSI_COLOR="0;31"\
CPE_NAME="cpe:/o:centos:centos:7"\
HOME_URL="https://www.centos.org/"\
BUG_REPORT_URL="https://bugs.centos.org/"\
CENTOS_MANTISBT_PROJECT="CentOS-7"\
CENTOS_MANTISBT_PROJECT_VERSION="7"\
REDHAT_SUPPORT_PRODUCT="centos"\
REDHAT_SUPPORT_PRODUCT_VERSION="7"\
As a side note, everything was starting normally with no issues until recently. As far as I know there haven't been any major changes to the environment. But, when I ran the "systemctl restart" command recently, the startup began to fail. There are 5 instances of Tomcat 9.0.33 running at different ports and paths and those have not changed. I have not restarted two of the instance (afraid they won't start) the other three flat out won't start. Details below:
Systemd unit file for tomcat\
[Unit]\
Description=Apache Tomcat Web Application Container in Liferay 7.32 TEST for UAT\
After=syslog.target network.target
[Service]\
Type=forking
Environment=JAVA_HOME=/opt/jdk1.8.0_121/jre\
Environment=CATALINA_PID=/opt/liferay/uatapi/liferay-ce-portal-7.3.2-ga3/tomcat-9.0.33/temp/tomcat.pid\
Environment=CATALINA_HOME=/opt/liferay/uatapi/liferay-ce-portal-7.3.2-ga3/tomcat-9.0.33\
Environment=CATALINA_BASE=/opt/liferay/uatapi/liferay-ce-portal-7.3.2-ga3/tomcat-9.0.33\
Environment='CATALINA_OPTS=-Xms1024m -Xmx2048m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:SurvivorRatio=20 -XX:ParallelGCThreads=8 -server -Xdebug -Xrunjdwp:transport=dt_socket,address=5000,server=y,suspend=n'\
Environment='JAVA_OPTS=-Djava.awt.headless=true -Djava.security.egd=file:/dev/./urandom -Duser.timezone=GMT -Dfile.encoding=UTF-8'
ExecStart=/opt/liferay/uatapi/liferay-ce-portal-7.3.2-ga3/tomcat-9.0.33/bin/startup.sh\
ExecStop=/bin/kill -15 $MAINPID
User=tomcat\
Group=tomcat\
UMask=0007
[Install]\
WantedBy=multi-user.target\
Results when running systemctl start liferayuat
● liferayuat.service - Apache Tomcat Web Application Container in Liferay 7.32 TEST for UAT\
Loaded: loaded (/etc/systemd/system/liferayuat.service; enabled; vendor preset: disabled)\
Active: failed (Result: exit-code) since Sat 2020-12-05 08:44:08 CST; 3s ago\
Process: 10891 ExecStop=/bin/kill -15 $MAINPID (code=exited, status=1/FAILURE)\
Process: 10851 ExecStart=/opt/liferay/uatapi/liferay-ce-portal-7.3.2-ga3/tomcat-9.0.33/bin/startup.sh \(code=exited, status=0/SUCCESS)\
Main PID: 10861 (code=exited, status=0/SUCCESS)
Dec 05 08:44:08 systemd[1]: Starting Apache Tomcat Web Application Container in Liferay 7.32 TEST for UAT...\
Dec 05 08:44:08 startup.sh[10851]: Existing PID file found during start.\
Dec 05 08:44:08 startup.sh[10851]: Removing/clearing stale PID file.\
Dec 05 08:44:08 startup.sh[10851]: Tomcat started.\
Dec 05 08:44:08 systemd[1]: Started Apache Tomcat Web Application Container in Liferay 7.32 TEST for UAT.\
Dec 05 08:44:08 systemd[1]: liferayuat.service: control process exited, code=exited status=1\
Dec 05 08:44:08 systemd[1]: Unit liferayuat.service entered failed state.\
Dec 05 08:44:08 systemd[1]: liferayuat.service failed.
Then the ONLY thing in catalina.out:
Listening for transport dt_socket at address: 5000\
java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina\
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)\
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)\
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)\
at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:261)\
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:443)\
So, when I start the instance with systemctl start it will fail. But if I run this command (as root...) then it will start:
/opt/liferay/uatapi/liferay-ce-portal-7.3.2-ga3/tomcat-9.0.33/bin/startup.sh
If I run that full commmand AS tomcat it doesn't start with the same error. So, it appears that the issue is permissions. The tomcat user and group are owners of all files and folders. But, somehow, the tomcat user either doesn't have permissions or the path gets jacked up so that the class files can't be found. I followed the suggestions in the article I referenced above but the changes had no impact.
I tripped across one article on SELINX that seemed to point to an issue there. This are the SELINUX settings:
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: permissive
Mode from config file: permissive
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 31\
The workaround to keep the instances running is just to manually start them but what is causing systemctl start NOT to work? I suspect permissions but I sure as heck can't see why since everything is owned by tomcat:tomcat

So, this is self-inflicted as most "mysteries" are. I still cannot account for some of the differences I see when looking into SELinux contexts between the instances but the REAL cause was subtle (to me). Permissions on the {tomcat root}/lib and {tomcat root}/lib/ext had no execute permissions. That may have been due to a jar that was added recently and then needed to be updated by owner and permissions. In any case, the original issue resulted in many trial and error attempts to fix it which complicated matters further.
I discovered the solution by doing a folder by folder, file by file comparison between working and non-working instances. Apparently the new jar and the owner/permission changes were applied to all but the production version.
Thanks for the suggestions.

Glassfish won't start in debug mode on windows

asadmin start-domain --debug=true
JDK: jdk1.8.0_172
Payara: 4.1.2.181
produces the following output.
Waiting for domain1 to start ..Error starting domain domain1.
The server exited prematurely with exit code 2.
Before it died, it produced the following output:
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=192m; support was removed in 8.0
ERROR: transport error 202: connect failed: Connection refused
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [debugInit.c:750]
Command start-domain failed.
The glassfish log file only contains this:
There are no additional clues as to why it cannot start in debug mode.
asadmin start-domain works just perfectly.
[2018-05-15T14:43:27.424+0200] [] [INFO] [NCLS-GFLAUNCHER-00005] [javax.enterprise.launcher] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1526388207424] [levelValue: 800] [[
JVM invocation command line:
C:\Program Files\Java\jdk1.8.0_172\bin\java.exe
-cp
C:/Java/payara41/glassfish/modules/glassfish.jar
-agentlib:jdwp=transport=dt_socket,address=9009,server=n,suspend=y
-XX:+UnlockDiagnosticVMOptions
-XX:NewRatio=2
-XX:MaxPermSize=192m
-Xmx512m
-javaagent:C:/Java/payara41/glassfish/lib/monitor/flashlight-agent.jar
-client
-Djavax.xml.accessExternalSchema=all
-Djavax.net.ssl.trustStore=C:\Java\payara41\glassfish\domains\domain1/config/cacerts.jks
-Djdk.tls.rejectClientInitiatedRenegotiation=true
-Djdk.corba.allowOutputStreamSubclass=true
-Dfelix.fileinstall.dir=C:\Java\payara41\glassfish/modules/autostart/
-Dorg.glassfish.additionalOSGiBundlesToStart=org.apache.felix.shell,org.apache.felix.gogo.runtime,org.apache.felix.gogo.shell,org.apache.felix.gogo.command,org.apache.felix.shell.remote,org.apache.felix.fileinstall
-Dcom.sun.aas.installRoot=C:\Java\payara41\glassfish
-Dfelix.fileinstall.poll=5000
-Djava.endorsed.dirs=C:\Java\payara41\glassfish/modules/endorsed;C:\Java\payara41\glassfish/lib/endorsed
-Djava.security.policy=C:\Java\payara41\glassfish\domains\domain1/config/server.policy
-Dosgi.shell.telnet.maxconn=1
-Dfelix.fileinstall.bundles.startTransient=true
-Dcom.sun.enterprise.config.config_environment_factory_class=com.sun.enterprise.config.serverbeans.AppserverConfigEnvironmentFactory
-Dfelix.fileinstall.log.level=2
-Djavax.net.ssl.keyStore=C:\Java\payara41\glassfish\domains\domain1/config/keystore.jks
-Djava.security.auth.login.config=C:\Java\payara41\glassfish\domains\domain1/config/login.conf
-Dfelix.fileinstall.disableConfigSave=false
-Dorg.glassfish.grizzly.DEFAULT_MEMORY_MANAGER=org.glassfish.grizzly.memory.HeapMemoryManager
-Dfelix.fileinstall.bundles.new.start=true
-Dcom.sun.aas.instanceRoot=C:\Java\payara41\glassfish\domains\domain1
-Dosgi.shell.telnet.port=6666
-Dgosh.args=--nointeractive
-Dcom.sun.enterprise.security.httpsOutboundKeyAlias=s1as
-Dorg.jboss.weld.serialization.beanIdentifierIndexOptimization=false
-Dosgi.shell.telnet.ip=127.0.0.1
-DANTLR_USE_DIRECT_CLASS_LOADING=true
-Djava.awt.headless=true
-Dcom.ctc.wstx.returnNullForDefaultNamespace=true
-Djava.ext.dirs=C:\Program Files\Java\jdk1.8.0_172/lib/ext;C:\Program Files\Java\jdk1.8.0_172/jre/lib/ext;C:\Java\payara41\glassfish\domains\domain1/lib/ext
-Djdbc.drivers=org.apache.derby.jdbc.ClientDriver
-Djava.library.path=C:/Java/payara41/glassfish/lib;C:/Program Files (x86)/Common Files/Oracle/Java/javapath;C:/Windows/Sun/Java/bin;C:/Windows/System32;C:/Windows;C:/Utilities;C:/Program Files/Common Files/microsoft shared/Microsoft Online Services;C:/Program Files (x86)/Common Files/microsoft shared/Microsoft Online Services;C:/ProgramData/Oracle/Java/javapath;C:/Windows/System32/wbem;C:/Windows/System32/WindowsPowerShell/v1.0;C:/Program Files/Intel/WiFi/bin;C:/Program Files/Common Files/Intel/WirelessCommon;C:/ProgramData/chocolatey/bin;C:/Program Files/Beyond Compare 4;C:/Users/QXV0615/AppData/Local/Microsoft/WindowsApps;C:/Program Files/PortableGit/cmd;C:/Users/QXV0615/AppData/Local/hyper/app-2.0.0/resources/bin;C:/Program Files/Microsoft VS Code;C:/Java/payara41/bin;C:/Program Files/Java/jdk1.8.0_172/bin;C:/Java/apache-maven-3.5.3/bin;C:/Users/QXV0615/AppData/Local/Programs/Git/cmd;C:/Bin;C:/Program Files/PostgreSQL/10/bin;C:/Projects/mcp/mcp
com.sun.enterprise.glassfish.bootstrap.ASMain
-upgrade
false
-domaindir
C:/Java/payara41/glassfish/domains/domain1
-read-stdin
true
-asadmin-args
--host,,,localhost,,,--port,,,4848,,,--secure=false,,,--terse=false,,,--echo=false,,,--interactive=true,,,start-domain,,,--verbose=false,,,--watchdog=false,,,--debug=true,,,--domaindir,,,C:\Java\payara41\glassfish\domains,,,domain1
-domainname
domain1
-instancename
server
-type
DAS
-verbose
false
-asadmin-classpath
C:/Java/payara41/glassfish/lib/client/appserver-cli.jar
-debug
true
-asadmin-classname
com.sun.enterprise.admin.cli.AdminMain
-watchdog
false]]
any tips on how I should resolve this?
edit
I have discovered that the domain.xml configuration files for debug startup were different between my version 172 and 181 are different.
174:
<java-config classpath-suffix="" debug-options="-agentlib:jdwp=transport=dt_socket,address=9009,server=n,suspend=y" java-home="C:\Program Files\Java\jdk1.8.0_172" system-classpath="">
181:
<java-config classpath-suffix="" debug-options="-agentlib:jdwp=transport=dt_socket,address=9009,server=n,suspend=y" java-home="C:\Program Files\Java\jdk1.8.0_172" system-classpath="">
The server, suspend and java-home are different. The JDK path in the configuration file is correct.
They now both start, but why?

That looks like the ports used by Payara are already in use. The most likely reason for that is you already have a running instance of Payara which you haven't stopped.
You check what ports are in use by running netstat -ano.
Also, ensure that the startup options in domain.xml are correct. Some IDE's like Intelij Idea might change the options for local debugging - which break remote debugging. The options need to be restored.

Cassandra 1 to Cassandra 2

I am trying to upgrade Cassandra 1 to Cassandra 2.. And to do that I upgraded Java (to Java 7) but whenever I execute : cassandra. Its launching like this :
INFO 17:32:41,413 Logging initialized INFO 17:32:41,437 Loading
settings from file:/etc/cassandra/cassandra.yaml INFO 17:32:41,642
Data files directories: [/var/lib/cassandra/data] INFO 17:32:41,643
Commit log directory: /var/lib/cassandra/commitlog INFO 17:32:41,643
DiskAccessMode 'auto' determined to be mmap, indexAccessMode is mmap
INFO 17:32:41,643 disk_failure_policy is stop INFO 17:32:41,643
commit_failure_policy is stop INFO 17:32:41,647 Global memtable
threshold is enabled at 986MB INFO 17:32:41,727 Not using
multi-threaded compaction INFO 17:32:41,869 JVM vendor/version:
OpenJDK 64-Bit Server VM/1.7.0_55 WARN 17:32:41,869 OpenJDK is not
recommended. Please upgrade to the newest Oracle Java release INFO
17:32:41,869 Heap size: 4137680896/4137680896 INFO 17:32:41,870 Code
Cache Non-heap memory: init = 2555904(2496K) used = 657664(642K)
committed = 2555904(2496K) max = 50331648(49152K) INFO 17:32:41,870
Par Eden Space Heap memory: init = 335544320(327680K) used =
80545080(78657K) committed = 335544320(327680K) max =
335544320(327680K) INFO 17:32:41,870 Par Survivor Space Heap memory:
init = 41943040(40960K) used = 0(0K) committed = 41943040(40960K) max
= 41943040(40960K) INFO 17:32:41,870 CMS Old Gen Heap memory: init = 3760193536(3672064K) used = 0(0K) committed = 3760193536(3672064K) max
= 3760193536(3672064K) INFO 17:32:41,872 CMS Perm Gen Non-heap memory: init = 21757952(21248K) used = 14994304(14642K) committed =
21757952(21248K) max = 174063616(169984K) INFO 17:32:41,872 Classpath:
/etc/cassandra:/usr/share/cassandra/lib/antlr-3.2.jar:/usr/share/cassandra/lib/commons-cli-1.1.jar:/usr/share/cassandra/lib/commons-codec-1.2.jar:/usr/share/cassandra/lib/commons-lang3-3.1.jar:/usr/share/cassandra/lib/compress-lzf-0.8.4.jar:/usr/share/cassandra/lib/concurrentlinkedhashmap-lru-1.3.jar:/usr/share/cassandra/lib/disruptor-3.0.1.jar:/usr/share/cassandra/lib/guava-15.0.jar:/usr/share/cassandra/lib/high-scale-lib-1.1.2.jar:/usr/share/cassandra/lib/jackson-core-asl-1.9.2.jar:/usr/share/cassandra/lib/jackson-mapper-asl-1.9.2.jar:/usr/share/cassandra/lib/jamm-0.2.5.jar:/usr/share/cassandra/lib/jbcrypt-0.3m.jar:/usr/share/cassandra/lib/jline-1.0.jar:/usr/share/cassandra/lib/json-simple-1.1.jar:/usr/share/cassandra/lib/libthrift-0.9.1.jar:/usr/share/cassandra/lib/log4j-1.2.16.jar:/usr/share/cassandra/lib/lz4-1.2.0.jar:/usr/share/cassandra/lib/metrics-core-2.2.0.jar:/usr/share/cassandra/lib/netty-3.6.6.Final.jar:/usr/share/cassandra/lib/reporter-config-2.1.0.jar:/usr/share/cassandra/lib/servlet-api-2.5-20081211.jar:/usr/share/cassandra/lib/slf4j-api-1.7.2.jar:/usr/share/cassandra/lib/slf4j-log4j12-1.7.2.jar:/usr/share/cassandra/lib/snakeyaml-1.11.jar:/usr/share/cassandra/lib/snappy-java-1.0.5.jar:/usr/share/cassandra/lib/snaptree-0.1.jar:/usr/share/cassandra/lib/super-csv-2.1.0.jar:/usr/share/cassandra/lib/thrift-server-internal-only-0.3.3.jar:/usr/share/cassandra/apache-cassandra-2.0.8.jar:/usr/share/cassandra/apache-cassandra.jar:/usr/share/cassandra/apache-cassandra-thrift-2.0.8.jar:/usr/share/cassandra/stress.jar::/usr/share/cassandra/lib/jamm-0.2.5.jar
INFO 17:32:41,873 JNA not found. Native methods will be disabled. INFO
17:32:41,884 Initializing key cache with capacity of 100 MBs. INFO
17:32:41,890 Scheduling key cache save to each 14400 seconds (going to
save all keys). INFO 17:32:41,890 Initializing row cache with capacity
of 0 MBs INFO 17:32:41,895 Scheduling row cache save to each 0 seconds
(going to save all keys). INFO 17:32:41,968 Initializing
system.schema_triggers INFO 17:32:41,985 Initializing
system.compaction_history INFO 17:32:41,988 Initializing
system.batchlog INFO 17:32:41,991 Initializing system.sstable_activity
INFO 17:32:41,994 Initializing system.peer_events INFO 17:32:41,997
Initializing system.compactions_in_progress INFO 17:32:42,000
Initializing system.hints ERROR 17:32:42,001 Exception encountered
during startup java.lang.RuntimeException: Incompatible SSTable found.
Current version jb is unable to read file:
/var/lib/cassandra/data/system/schema_keyspaces/system-schema_keyspaces-hf-2.
Please run upgradesstables. at
org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:415)
at
org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:392)
at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:309) at
org.apache.cassandra.db.Keyspace.<init>(Keyspace.java:266) at
org.apache.cassandra.db.Keyspace.open(Keyspace.java:110) at
org.apache.cassandra.db.Keyspace.open(Keyspace.java:88) at
org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:536)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:261)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:496)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:585)
java.lang.RuntimeException: Incompatible SSTable found. Current
version jb is unable to read file:
/var/lib/cassandra/data/system/schema_keyspaces/system-schema_keyspaces-hf-2.
Please run upgradesstables. at
org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:415)
at
org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:392)
at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:309) at
org.apache.cassandra.db.Keyspace.<init>(Keyspace.java:266) at
org.apache.cassandra.db.Keyspace.open(Keyspace.java:110) at
org.apache.cassandra.db.Keyspace.open(Keyspace.java:88) at
org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:536)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:261)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:496)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:585)
Exception encountered during startup: Incompatible SSTable found.
Current version jb is unable to read file:
/var/lib/cassandra/data/system/schema_keyspaces/system-schema_keyspaces-hf-2.
Please run upgradesstables.
When i try to execute : upgradesstables (nodetool upgradesstables -h 127.0.0.1 -u root ...) I got this :
Failed to connect to '127.0.0.1:7000': Connexion refusée
Anyone can help me please ?
Thanks.

The Cassandra error has nothing to do with OpenJDK, although I do recommend using Oracle's.
You need to make sure you're on a valid upgrade path: http://docs.datastax.com/en/upgrade/doc/upgrade/cassandra/upgradeC_c.html
You can't trivially upgrade from a Cassandra older than 1.2.9 to 2.0, and you can't upgrade from 1.x to 2.1 without first going to 2.0.7 or later.
Suggested upgrade path per documentation: 1.x > 1.2.9 > 2.0.7 > 2.1.x

Your java -version output shows your not using correct JDK. It should be something like below.
Java version "1.8.0_65"
Java(TM) SE Runtime Environment (build 1.8.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.65-b01, mixed mode)
For this tell the system that there's a new Java version available
$ sudo update-alternatives --install "/usr/bin/java" "java" "/usr/lib/jvm/jdk1.8.0_version/bin/java" 1
Set the new JDK as the default using the following command:
$ sudo update-alternatives --config java
You can refer the link https://devopsmanual.in/2018/03/07/how-to-upgrade-datastax-cassandra/ for more details.

Sinatra Jruby Heroku - jruby: No such file or directory -- trinidad (LoadError)

I'm trying to get this application running: github.com/Soliah/sinatra-jruby-heroku.git
One update was necessary according to this release note from Heroku:
http://devcenter.heroku.com/articles/release-note-java-2011-09-29
The build goes fine, without any errors. Bellow some log parts:
[INFO] --- jruby-rake-plugin:1.6.3:jruby (install-bundler) # jruby-heroku ---
[INFO] Successfully installed bundler-1.0.21
[INFO] 1 gem installed
[INFO]
[INFO] --- jruby-rake-plugin:1.6.3:jruby (bundle-install) # jruby-heroku ---
[INFO] Fetching source index for http://rubygems.org/
[INFO] Installing jruby-rack (1.0.10)
[INFO] Installing rack (1.3.2)
[INFO] Installing tilt (1.3.3)
[INFO] Installing sinatra (1.2.6)
[INFO] Installing trinidad_jars (1.0.1)
[INFO] Installing trinidad (1.2.3)
[INFO] Using bundler (1.0.21)
[INFO] Your bundle is complete! It was installed into ./vendor/bundle
(...)
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 33.408s
[INFO] Finished at: Tue Jan 31 10:58:03 UTC 2012
[INFO] Final Memory: 9M/490M
[INFO] ------------------------------------------------------------------------
-----> Discovering process types
Procfile declares types -> jruby, web
-----> Compiled slug size is 18.6MB
-----> Launching... done, v5
http://jrubyandjava.herokuapp.com deployed to Heroku
But when I access the deployed application. An application error occurs.
Here is the log, with the error:
$ heroku logs
2012-01-31T10:57:21+00:00 heroku[slugc]: Slug compilation started
2012-01-31T10:58:13+00:00 heroku[web.1]: State changed from created to starting
2012-01-31T10:58:19+00:00 heroku[web.1]: Starting process with command `sh script/jruby -S trinidad -p 52233`
2012-01-31T10:58:20+00:00 app[web.1]: Classpath is: :/app/etc:/app/target/dependency/jruby-complete.jar
2012-01-31T10:58:21+00:00 app[web.1]: jruby: No such file or directory -- trinidad (LoadError)
2012-01-31T10:58:23+00:00 heroku[web.1]: State changed from starting to crashed
2012-01-31T10:58:23+00:00 heroku[web.1]: State changed from crashed to created
2012-01-31T10:58:23+00:00 heroku[web.1]: State changed from created to starting
2012-01-31T10:58:23+00:00 heroku[web.1]: Process exited
2012-01-31T10:58:28+00:00 heroku[web.1]: Starting process with command `sh script/jruby -S trinidad -p 26224`
2012-01-31T10:58:28+00:00 app[web.1]: Classpath is: :/app/etc:/app/target/dependency/jruby-complete.jar
2012-01-31T10:58:31+00:00 app[web.1]: jruby: No such file or directory -- trinidad (LoadError)
2012-01-31T10:58:32+00:00 heroku[web.1]: State changed from starting to crashed
2012-01-31T10:58:33+00:00 heroku[web.1]: Process exited
2012-01-31T10:58:33+00:00 heroku[router]: Error H10 (App crashed) -> GET jrubyandjava.herokuapp.com/ dyno= queue= wait= service= status=503 bytes=
It seems that JRuby is not finding the gems.
But I've tried all kinds of configurations (in script/jruby, heroku config:add, Procfile, etc.) and no one worked.
One more thing: this is the actual heroku config output (stack cedar).
$ heroku config
DATABASE_URL => postgres://kfgubrhars:mYBlJ2YKewqG7LwmPqVI#ec2-50-17-200-129.compute-1.amazonaws.com/kfgubrhars
JAVA_OPTS => -Xmx384m -Xss512k -XX:+UseCompressedOops
MAVEN_OPTS => -Xmx384m -Xss512k -XX:+UseCompressedOops
PATH => /usr/local/bin:/usr/bin:/bin
SHARED_DATABASE_URL => postgres://kfgubrhars:mYBlJ2YKewqG7LwmPqVI#ec2-50-17-200-129.compute-1.amazonaws.com/kfgubrhars
Here is the updated repository: https://github.com/tomasmuller/sinatra-jruby-heroku
Thank's in advance!

Ok! I found the solution. Here are the steps:
Adjust the GEM_HOME, in script/jruby to:
GEM_HOME="$APPDIR"/vendor/bundle
Created the script/bundle, with ENV['GEM_HOME'] and ENV['GEM_PATH'] pointing to 'vendor/bundle' dir.
Adjusted the executions of jruby-rake-plugin, in pom.xml:
install-bundler: <args>-S gem install bundler --no-ri --no-rdoc --install-dir vendor/bundle</args>
bundle-install: <args>script/bundle install --without development:test</args>

There's been a recent change to where the gems get installed. The launcher script/jruby expects the gems to be in .gems but it looks like that has now changed to vender/bundle.
Try changing the line https://github.com/tomasmuller/sinatra-jruby-heroku/blob/master/script/jruby#L94 to export GEM_HOME="$APPDIR"/vender/bundle instead.
I've been meaning to update my blog post with these changes but just haven't got around to it.

As of Bundler 1.2 you are now able to specify the Ruby implementation and version in your Gemfile. The nice thing about this is that Heroku will understand these settings and prepare the your Heroku application for your environment.
Take this Gemfile for example:
source "https://rubygems.org"
ruby "1.9.3"
gem "rails"
gem "puma"
What's cool about this is that by default Celadon Cedar uses Ruby 1.9.2. However, when you specify ruby "1.9.3" in the Gemfile it'll actually compile Ruby 1.9.3 for your Heroku environment.
Now, if you want to add a different Ruby implementation to your Heroku environment, you can do so like this:
source "https://rubygems.org"
ruby "1.9.3", :engine => "jruby", :engine_version => "1.7.0.preview1"
gem "rails"
gem "puma"
Now it'll install and use JRuby 1.7.0.preview1 in Ruby 1.9 mode for your Heroku application upon deployment. It'll also even define the proper JVM options in the Heroku environment variables.
Best of all is that this comes with the official Heroku buildpack, so there is no need to switch to a 3rd party buildpack to get the JRuby/JVM going on Heroku. Although I haven't gotten it to work yet, this should also work with Rubinius, but I believe it's currently bugged. Either that, or I'm doing it wrong.
This is in my opinion an awesome and scalable feature. Just define the Ruby implementation/version/mode you're using in your Gemfile along with your other dependencies and Heroku will ensure the environment is prepared.
It is no longer necessary to use a workaround or use 3rd party buildpacks using this method. It is also no longer necessary to create a hacky Jemfile. Instead, just do everything as you would normally do with MRI, keep the Gemfile, don't use 3rd party buildpacks, just define the Ruby implementation/runtime in the Gemfile via the ruby method and Heroku should take care of things.

Hudson build always end up in "java.lang.OutOfMemoryError: Java heap space" error

I'm having a problem with the Hudson build slave which has got Windows XP and 4 GB RAM and in the batch file to call the JNLP I have specify like the following:
javaws -J-Xms1280m -J-Xmx1024m http://hudson-master.domain.com:8080/computer/Exige/slave-agent.jnlp
Why can't I give it more than 1 GB ?
The system is out of resources.
Consult the following stack trace for details.
java.lang.OutOfMemoryError: Java heap space
at com.sun.tools.javac.util.List.prepend(List.java:145)
at com.sun.tools.javac.jvm.ClassReader.openArchive(ClassReader.java:1457)
at com.sun.tools.javac.jvm.ClassReader.list(ClassReader.java:1742)
at com.sun.tools.javac.jvm.ClassReader.listAll(ClassReader.java:1882)
at com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:1903)
at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:1538)
at com.sun.tools.javac.code.Symbol.complete(Symbol.java:355)
at com.sun.tools.javac.comp.Enter.visitTopLevel(Enter.java:256)
at com.sun.tools.javac.tree.Tree$TopLevel.accept(Tree.java:382)
at com.sun.tools.javac.comp.Enter.classEnter(Enter.java:221)
at com.sun.tools.javac.comp.Enter.classEnter(Enter.java:235)
at com.sun.tools.javac.comp.Enter.complete(Enter.java:448)
at com.sun.tools.javac.comp.Enter.main(Enter.java:433)
at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:404)
at com.sun.tools.javac.main.Main.compile(Main.java:592)
at com.sun.tools.javac.main.Main.compile(Main.java:544)
at com.sun.tools.javac.Main.compile(Main.java:85)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.plexus.compiler.javac.JavacCompiler.compileInProcess(JavacCompiler.java:420)
at org.codehaus.plexus.compiler.javac.JavacCompiler.compile(JavacCompiler.java:141)
at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:493)
at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:114)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
at hudson.maven.agent.PluginManagerInterceptor.executeMojo(PluginManagerInterceptor.java:182)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch [INFO] ------------------------------------------------------------------------
[INFO] Total time: 34 seconds
[INFO] Finished at: Fri Oct 08 17:27:59 EST 2010 [INFO] Final Memory: 25M/63M [INFO] ------------------------------------------------------------------------

The Xms should generally be lower than the Xmx

Is the build executed directly by the JVM of the slave agent? If you run a Maven build (for example), the slave agent can launch an external Maven process (with default Java Xmx).
So you should specify the MAVEN_OPTS parameter to ensure that Maven builds are always executed with a customized Xmx value.

If you have Master Slave configuration, you should specify the memory settings in the Manage Hudson->Configure system->Global properties
The kind of Environment properties present on Master are used in Slave too.

Please note: On 32-bit Windows, a Java VM cannot allocate more than about 1 GB. Don't ask me why, but that's the case (at least it's the case for the Sun JVM). You need a 64 bit system if you need more memory for your JVM. And a 64-bit JVM, of course.