https://bugzilla.redhat.com/show_bug.cgi?id=1169102
Bug ID: 1169102
Summary: [abrt] tomcat-7.0.52-2.fc20: Uncaught exception
java.lang.RuntimeException in method
java.util.concurrent.ThreadPoolExecutor.runWorker()
Product: Fedora
Version: 20
Component: tomcat
Assignee: ivan.afonichev(a)gmail.com
Reporter: kkibwage(a)yahoo.com
QA Contact: extras-qa(a)fedoraproject.org
CC: ivan.afonichev(a)gmail.com,
java-sig-commits(a)lists.fedoraproject.org,
krzysztof.daniel(a)gmail.com
Version-Release number of selected component:
tomcat-7.0.52-2.fc20
Additional info:
reporter: libreport-2.2.3
cmdline: java -agentpath:/usr/lib64/libabrt-java-connector.so=abrt=on
-classpath
/usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar
-Dcatalina.base=/usr/share/tomcat -Dcatalina.home=/usr/share/tomcat
-Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat/temp
-Djava.util.logging.config.file=/usr/share/tomcat/conf/logging.properties
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
org.apache.catalina.startup.Bootstrap start
executable: /usr/share/tomcat/bin/bootstrap.jar
java_executable:
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre-abrt/bin/java
kernel: 3.17.3-200.fc20.x86_64
pid: 1494
runlevel: N 5
uid: 91
Truncated backtrace:
Exception in thread "http-bio-8080-exec-3" java.lang.RuntimeException: Stopping
thread http-bio-8080-exec-3 to avoid potential memory leaks after a context was
stopped.
at
org.apache.tomcat.util.threads.ThreadPoolExecutor.stopCurrentThreadIfNeeded(ThreadPoolExecutor.java:129)
[jar:file:/usr/share/java/tomcat/tomcat-coyote.jar!/org/apache/tomcat/util/threads/ThreadPoolExecutor.class]
at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:90)
[jar:file:/usr/share/java/tomcat/tomcat-coyote.jar!/org/apache/tomcat/util/threads/TaskQueue.class]
at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:32)
[jar:file:/usr/share/java/tomcat/tomcat-coyote.jar!/org/apache/tomcat/util/threads/TaskQueue.class]
at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
[jar:file:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre/lib/rt.jar!/java/util/concurrent/ThreadPoolExecutor.class]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
[jar:file:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre/lib/rt.jar!/java/util/concurrent/ThreadPoolExecutor.class]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[jar:file:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre/lib/rt.jar!/java/util/concurrent/ThreadPoolExecutor$Worker.class]
at java.lang.Thread.run(Thread.java:745)
[jar:file:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre/lib/rt.jar!/java/lang/Thread.class]
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=GtkS5uBD5s&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1169095
Bug ID: 1169095
Summary: [abrt] tomcat-7.0.52-2.fc20: Uncaught exception
java.lang.RuntimeException in method
java.util.concurrent.ThreadPoolExecutor.runWorker()
Product: Fedora
Version: 20
Component: tomcat
Assignee: ivan.afonichev(a)gmail.com
Reporter: kkibwage(a)yahoo.com
QA Contact: extras-qa(a)fedoraproject.org
CC: ivan.afonichev(a)gmail.com,
java-sig-commits(a)lists.fedoraproject.org,
krzysztof.daniel(a)gmail.com
Description of problem:
i was undeploying an app
Version-Release number of selected component:
tomcat-7.0.52-2.fc20
Additional info:
reporter: libreport-2.2.3
cmdline: java -agentpath:/usr/lib64/libabrt-java-connector.so=abrt=on
-classpath
/usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar
-Dcatalina.base=/usr/share/tomcat -Dcatalina.home=/usr/share/tomcat
-Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat/temp
-Djava.util.logging.config.file=/usr/share/tomcat/conf/logging.properties
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
org.apache.catalina.startup.Bootstrap start
executable: /usr/share/tomcat/bin/bootstrap.jar
java_executable:
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre-abrt/bin/java
kernel: 3.17.3-200.fc20.x86_64
pid: 1494
runlevel: N 5
uid: 91
Truncated backtrace:
Exception in thread "http-bio-8080-exec-4" java.lang.RuntimeException: Stopping
thread http-bio-8080-exec-4 to avoid potential memory leaks after a context was
stopped.
at
org.apache.tomcat.util.threads.ThreadPoolExecutor.stopCurrentThreadIfNeeded(ThreadPoolExecutor.java:129)
[jar:file:/usr/share/java/tomcat/tomcat-coyote.jar!/org/apache/tomcat/util/threads/ThreadPoolExecutor.class]
at
org.apache.tomcat.util.threads.ThreadPoolExecutor.afterExecute(ThreadPoolExecutor.java:100)
[jar:file:/usr/share/java/tomcat/tomcat-coyote.jar!/org/apache/tomcat/util/threads/ThreadPoolExecutor.class]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
[jar:file:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre/lib/rt.jar!/java/util/concurrent/ThreadPoolExecutor.class]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[jar:file:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre/lib/rt.jar!/java/util/concurrent/ThreadPoolExecutor$Worker.class]
at java.lang.Thread.run(Thread.java:745)
[jar:file:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre/lib/rt.jar!/java/lang/Thread.class]
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=zbwT3JSe4B&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1167033
Bug ID: 1167033
Summary: All tomcat at name instances run under the same tomcat
user
Product: Fedora
Version: 20
Component: tomcat
Assignee: ivan.afonichev(a)gmail.com
Reporter: bowabos(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: ivan.afonichev(a)gmail.com,
java-sig-commits(a)lists.fedoraproject.org,
krzysztof.daniel(a)gmail.com
Description of problem:
It should be possible to specify TOMCAT_USER variable in /etc/sysconfig/name to
change the user under which the name instance will run.
Version-Release number of selected component (if applicable):
How reproducible: easy
Steps to Reproduce:
1. create a second named instance
2. set TOMCAT_USER to a defined user (i.e. jira)
3. start the tomcat@name instance (i.e. tomcat@jira)
Actual results:
ps -ef | grep java shows the user is tomcat
Expected results:
ps -ef | grep java should return a process owned by the named tomcat instance
(i.e. jira)
Additional info:
modifying /usr/lib/systemd/system/tomcat@.service
and changing the User and Group line with
User=%I
Group=%I
may be an option explored.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=c32RhcyRMh&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1144270
Bug ID: 1144270
Summary: SBT doesn't start correctly in some 32-bit machines
due to low memory
Product: Fedora
Version: 20
Component: sbt
Assignee: willb(a)redhat.com
Reporter: dugucloud(a)qq.com
QA Contact: extras-qa(a)fedoraproject.org
CC: java-sig-commits(a)lists.fedoraproject.org, s(a)shk.io,
willb(a)redhat.com
Description of problem:
When starting SBT, Java reports cannot start VM because it cannot reserve
enough heap.
Version-Release number of selected component (if applicable):
0.13.1
How reproducible:
Every time on my machine.
Steps to Reproduce:
Run command sbt in console and see the console output.
Actual results:
'''
$ sbt
Error occurred during initialization of VM
Could not reserve enough space for object heap
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
'''
Expected results:
SBT works fine.
Additional info:
My machine is 32-bit. When I start SBT, my memory usage is 0.8 GiB / 2.5 GiB,
swap usage 0 GiB / 3.8GiB.
But after I modified the memory settings of Java in my SBT script
(/usr/bin/sbt), I can run it. These are the last few lines of my modified:
'''
export BASE_CLASSPATH=$(build-classpath scala ivy sbt ${JLINE} jansi
test-interface sbinary)
export JAVA_OPTS="-Xms256m -Xmx1024m -Xss1M -XX:+CMSClassUnloadingEnabled
-XX:MaxHeapSize=1000m -XX:MaxPermSize=256m"
java ${JAVA_OPTS} -Dfedora.sbt.boot.dir=${SBT_BOOT_DIR}
-Dfedora.sbt.ivy.dir=${SBT_IVY_DIR}
-Dsbt.boot.properties=${SBT_BOOT_PROPERTIES} -cp ${BASE_CLASSPATH}
xsbt.boot.Boot "$@"
'''
This is the StackOverflow question where I found my way:
https://stackoverflow.com/questions/4401396/could-not-reserve-enough-space-…
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=sZuZ0ALIyT&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1122149
Bug ID: 1122149
Summary: Custom boot.properties cause serious issues
Product: Fedora
Version: 20
Component: sbt
Severity: high
Assignee: willb(a)redhat.com
Reporter: th0br0(a)mkdir.name
QA Contact: extras-qa(a)fedoraproject.org
CC: java-sig-commits(a)lists.fedoraproject.org, s(a)shk.io,
willb(a)redhat.com
Description of problem:
Running sbt projects with sbt installed from Fedora's repository causes various
issues with different projects. From classpath issues to ivy2 issues to ...
Also see https://github.com/scalatest/scalatest/issues/248 for some examples.
Fix: remove Fedora sbt and install sbt as per
http://www.scala-sbt.org/release/tutorial/Manual-Installation.html
Prior to Fedora providing a custom ivy root etc. (I last tested on fc17) the
Fedora-provided sbt worked just fine AFAIR.
Version-Release number of selected component (if applicable):
only tested on 0.13.1-5.fc20
How reproducible:
Steps to Reproduce:
1. git clone https://github.com/miguno/kafka-storm-starter
2. cd kafka-storm-starter
3. sbt test
(4. disable forking or stop NetworkManager ... which somehow seems to fix the
issue)
Actual results:
[error] Uncaught exception when running tests: java.net.NoRouteToHostException:
No route to host
sbt.ForkMain$ForkError: No route to host
Expected results:
tests run
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=wpkqnjoTiO&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1112196
Bug ID: 1112196
Summary: The sbt package should use upstream launch scripts
Product: Fedora
Version: 20
Component: sbt
Assignee: willb(a)redhat.com
Reporter: code(a)oleastre.be
QA Contact: extras-qa(a)fedoraproject.org
CC: java-sig-commits(a)lists.fedoraproject.org, s(a)shk.io,
willb(a)redhat.com
Description of problem:
Current fedora sbt package uses a custom launch script that does not support
options provided by upstream. You can find in the upstream rpm package at:
http://www.scala-sbt.org/0.13/tutorial/Installing-sbt-on-Linux.html
Launch scripts are available at:
https://github.com/sbt/sbt-launcher-package
Version-Release number of selected component (if applicable):
sbt-0.13.1-5.fc20
Current fedora package can probably be used to build rpm packages for some
scala based projects, but it can not be used by scala developers for their
daily job.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=MXOutkGmg6&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1090765
Bug ID: 1090765
Summary: Scala projects containing the sbteclipse plugin fail
to build
Product: Fedora
Version: 20
Component: sbt
Severity: high
Assignee: willb(a)redhat.com
Reporter: gvdmer(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: java-sig-commits(a)lists.fedoraproject.org, s(a)shk.io,
willb(a)redhat.com
Description of problem:
Scala project will not build in sbt 0.13.1 and Scala 2.10.3 unless I DO NOT try
to add the sbteclipse plugin (2.4.0)
Version-Release number of selected component (if applicable):
sbt 0.13.1
How reproducible:
Every time.
Steps to Reproduce:
1. "yum install -y java", "yum install -y scala", and "yum install -y sbt."
This installed OpenJDK 1.7.0_51, Scala 2.10.3, and sbt 0.13.1.
2. plugins.sbt contains the line "addSbtPlugin("com.typesafe.sbteclipse" %
"sbteclipse-plugin" % "2.4.0")"
Actual results:
Building the project generates the following error:
"sbt.ResolveException: unresolved dependency:
org.scala-lang#scala-library;2.10.3: configuration not found in
org.scala-lang#scala-library;2.10.3: 'compile'."
Expected results:
Project builds.
Additional info:
This is a problem whether the plugins.sbt is located in /project, or in
~/.sbt/0.13/plugins.
I encountered this problem attempting to build
https://github.com/liftmodules/widgets
When I comment-out the "addSbtPlugin.... sbteclipse-plugin" line from the
plugins.sbt, the build functions normally.
I recreated the problem using a simple test project that just creates a single
Scala class with a one-line print statement. The problem continues to occur
independently of whatever other plugins, repositories, or library dependencies
I define in the plugins.sbt and build.sbt files.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=1ghlw6cYfy&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1083130
Bug ID: 1083130
Summary: Memory options should not be set in /usr/bin/sbt
Product: Fedora
Version: 20
Component: sbt
Assignee: willb(a)redhat.com
Reporter: rocketraman(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: java-sig-commits(a)lists.fedoraproject.org,
skottler(a)redhat.com, willb(a)redhat.com
Description of problem:
/usr/bin/sbt sets the JVM memory options for sbt. Also, the values are not sane
-- the max perm gen size is left at the default of 64 MB which is too small.
When running the upstream version of sbt, the memory and GC options by default
are:
-Xms1024m -Xmx1024m -XX:MaxPermSize=256m -XX:ReservedCodeCacheSize=128m
When running the Fedora version of sbt, the options are:
-Xms512M -Xmx1536M -Xss1M -XX:+CMSClassUnloadingEnabled
This is surprising behavior to say the least. In addition, the Fedora options
cannot be overwridden because /usr/bin/sbt does not check if JAVA_OPTS is
already defined before clobbering it.
Version-Release number of selected component (if applicable):
sbt-0.13.1-5.fc20.noarch
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=lrpKiQOfRe&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1021292
Bug ID: 1021292
Summary: Transaction check error when upgrading jogl2
Product: Fedora
Version: 20
Component: jogl2
Assignee: c.david86(a)gmail.com
Reporter: asaha(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: c.david86(a)gmail.com,
java-sig-commits(a)lists.fedoraproject.org
Description of problem:
# rpm -q jogl2
jogl2-2.0-0.11.rc12.fc20.x86_64
# yum -y update jogl2
Loaded plugins: langpacks, refresh-packagekit
Resolving Dependencies
--> Running transaction check
---> Package jogl2.x86_64 0:2.0-0.11.rc12.fc20 will be updated
---> Package jogl2.x86_64 0:2.0.2-1.fc20 will be an update
--> Finished Dependency Resolution
Dependencies Resolved
==============================================================================================================================================================================================
Package Arch
Version Repository
Size
==============================================================================================================================================================================================
Updating:
jogl2 x86_64
2.0.2-1.fc20 updates-testing
4.0 M
Transaction Summary
==============================================================================================================================================================================================
Upgrade 1 Package
Total size: 4.0 M
Downloading packages:
Running transaction check
Running transaction test
Transaction check error:
file /usr/share/doc/jogl2/bouml from install of jogl2-2.0.2-1.fc20.x86_64
conflicts with file from package jogl2-2.0-0.11.rc12.fc20.x86_64
Error Summary
-------------
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1. See above
2.
3.
Actual results:
Expected results:
Clean ugpgrade
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=YU8riko2Sl&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1008091
Bug ID: 1008091
Summary: Building with tycho seems to fail on arm builders
Product: Fedora
Version: 20
Component: tycho
Assignee: rgrunber(a)redhat.com
Reporter: gerard(a)ryan.lt
QA Contact: extras-qa(a)fedoraproject.org
CC: java-sig-commits(a)lists.fedoraproject.org,
kdaniel(a)redhat.com, mizdebsk(a)redhat.com,
rgrunber(a)redhat.com
Description of problem:
I'm trying to build eclipse-jbosstools, but every time that an arm builder is
chosen in koji, the build fails. I'm not sure exactly if the problem is with
tycho, but it looks like it's tycho/maven related.
How reproducible:
It seems to be only on armv7hl. Also, I've only run into the problem on f20,
since that's the only place I seem to have been given arm builders. Incredibly,
on my 4 attempts, the two scratch builds have been done on x86, so then I go to
do a real build, thinking everything is fine, and I get an arm one and it
fails.
Passes:
http://koji.fedoraproject.org/koji/taskinfo?taskID=5933066http://koji.fedoraproject.org/koji/taskinfo?taskID=5925100
Failures:
http://koji.fedoraproject.org/koji/taskinfo?taskID=5925234http://koji.fedoraproject.org/koji/taskinfo?taskID=5933332
Here's the build.log from one of the failures (I think those get cleared after
a week or so): http://galileo.fedorapeople.org/arm-build.log
Additional info:
I was talking to Dennis Gilmore on #fedora-devel about this, and he mentioned
that if necessary, he can provide access to arm systems to test/debug on.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=ZGobfEfjEs&a=cc_unsubscribe