January 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-4294) The xxx.conf.bat files do not set java.awt.headless=true

by Brian Stansberry (Jira)

Brian Stansberry created WFCORE-4294: ---------------------------------------- Summary: The xxx.conf.bat files do not set java.awt.headless=true Key: WFCORE-4294 URL: https://issues.jboss.org/browse/WFCORE-4294 Project: WildFly Core Issue Type: Bug Components: Scripts Affects Versions: 8.0.0.Beta3 Reporter: Brian Stansberry The standalone.conf and domain.comf files include -Djava.awt.headless=true in the default JAVA_OPTS but its not there in the Windows scripts. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4293) Command embed-server unrecognized arguments --jboss-home but in help it still a valid argument

by Vratislav Marek (Jira)

Vratislav Marek created WFCORE-4293: --------------------------------------- Summary: Command embed-server unrecognized arguments --jboss-home but in help it still a valid argument Key: WFCORE-4293 URL: https://issues.jboss.org/browse/WFCORE-4293 Project: WildFly Core Issue Type: Bug Components: CLI Affects Versions: 8.0.0.Beta3, 7.0.0.Final Reporter: Vratislav Marek Assignee: Jean-Francois Denise Command "_embed-server_" unrecognize argument "_--jboss-home_". {code:java} [disconnected /] embed-server --jboss-home=/tmp/2019-01-25/WFCORE-1187/firstLog Unrecognized arguments: [--jboss-home] {code} {code:java} [disconnected /] embed-server --jboss-home="/tmp/2019-01-25/WFCORE-1187/firstLog" Unrecognized arguments: [--jboss-home] {code} But in command help is written like a valid argument. {code:java} [disconnected /] help embed-server SYNOPSIS embed-server [--admin-only=true|false] [-c=config_file || --server-config=config_file] [--empty-config --remove-existing-config] [--jboss-home=rootdir] [--stdout=discard|echo] DESCRIPTION Launches a standalone server embedded in the CLI process. ARGUMENTS ... --jboss-home - Filesystem path pointing to the root directory of the installation from which the embedded server should run. Only available if the CLI itself is not running in a modular classloading environment. In a non-modular classloading environment, if this option is not specified, the value of the environment variable JBOSS_HOME will be used. Must be specified if the environment variable JBOSS_HOME is not set.In a modular classloading environment it is assumed the CLI is running from the server installation itself and the JBOSS_HOME environment variable must be set. ... {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4086) If a ManagedExecutorService's Runnable throws an exception, it should not be eaten (but it's stacktrace should be shown in the console) by default

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-4086?page=com.atlassian.jira.plugin.... ] Brian Stansberry resolved WFLY-4086. ------------------------------------ Assignee: (was: Jason Greene) Resolution: Duplicate Issue > If a ManagedExecutorService's Runnable throws an exception, it should not be eaten (but it's stacktrace should be shown in the console) by default > -------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-4086 > URL: https://issues.jboss.org/browse/WFLY-4086 > Project: WildFly > Issue Type: Enhancement > Components: EE > Affects Versions: 8.1.0.Final > Reporter: Geoffrey De Smet > Priority: Major > > To reproduce: > {code} > @Resource(name = "DefaultManagedExecutorService") > ManagedExecutorService executor; > public String myRestMethod() { > executor.submit(new SolverCallable()); > return "Submitted."; > } > private class SolverCallable implements Runnable { > public void run() { > throw new IllegalStateException("Tweety bird: Please Sylvester, don't eat me!"); > } > } > {code} > Poor tweety bird's plea (nor the stacktrace) doesn't show up in the WildFly console of a vanilla installation. > This led me to believe I had no error. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4055) Show more details for the EJB SessionBean statistic

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-4055?page=com.atlassian.jira.plugin.... ] Brian Stansberry reassigned WFLY-4055: -------------------------------------- Assignee: (was: Jason Greene) > Show more details for the EJB SessionBean statistic > --------------------------------------------------- > > Key: WFLY-4055 > URL: https://issues.jboss.org/browse/WFLY-4055 > Project: WildFly > Issue Type: Enhancement > Components: EJB > Affects Versions: 8.1.0.Final, 9.0.0.Alpha1 > Reporter: Wolf-Dieter Fink > Priority: Major > > The JMX MBeans in former versions <7 show more statistics. > As this counters can be important they should be collected in WildFly as well. > SLSB: > Current- Available- Max- (pool), Remove, Create > SFSB: > CacheSize, CreateSize, InvocStat, PassivatedCount, Current, RemoveCount, Available, Max, Total > As there is no pool possible for SFSB there is no Create and Remove counter for pooling and no counter of current instances. > These counters should be added -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3653) Managed Executors: unhandled exceptions should be logged

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-3653?page=com.atlassian.jira.plugin.... ] Brian Stansberry reassigned WFLY-3653: -------------------------------------- Assignee: Eduardo Martins (was: Jason Greene) > Managed Executors: unhandled exceptions should be logged > -------------------------------------------------------- > > Key: WFLY-3653 > URL: https://issues.jboss.org/browse/WFLY-3653 > Project: WildFly > Issue Type: Enhancement > Components: EE > Affects Versions: 8.1.0.Final > Reporter: Rich DiCroce > Assignee: Eduardo Martins > Priority: Major > > If you submit a task to a ManagedExecutorService, and the task throws an exception that propagates out of the task, the exception is not logged anywhere. Obviously, developers can simply wrap their task's code with a try-catch, but it would be nice if that were not needed. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3836) Unable to undeploy an application when it is running long time EJB calls.

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-3836?page=com.atlassian.jira.plugin.... ] Brian Stansberry resolved WFLY-3836. ------------------------------------ Fix Version/s: 16.0.0.Beta1 Assignee: Brian Stansberry (was: Jason Greene) Resolution: Partially Completed I'm resolving this as partially completed as there are a couple things that have been done to mitigate this: 1) The suspend management op used with graceful shutdown can also be used independently and should be used before non-shutdown/reload undeploy or redeploy. This is only tangentially relevant as it does not result in interrupting ongoing work. 2) The WFCORE-1632 work will interrupt ongoing work during shutdown/reload. Whether it would interrupt this particular scenario, I don't know, it depends on the details of what threads are running the long-running tasks. The WFCORE-1632 interrupt requires a shutdown or reload though, as it triggered by the termination of the thread pools, which are not specific to a deployment. Having deployment-specific services track what threads are executing tasks on the service's behalf so they can interrupt them as part of service stop would be theoretically better and would eliminate the need to shutdown/reload to get this behavior but it would also be quite complex to implement and would carry a performance penalty from the task tracking. So it's unlikely to happen. > Unable to undeploy an application when it is running long time EJB calls. > ------------------------------------------------------------------------- > > Key: WFLY-3836 > URL: https://issues.jboss.org/browse/WFLY-3836 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 8.1.0.Final > Reporter: Dominik Pospisil > Assignee: Brian Stansberry > Priority: Major > Fix For: 16.0.0.Beta1 > > > To update an application that is running, replace command from the management console is used. Therefore, first, the application needs to undeploy. > After org.jboss.as.web.deployment.WebDeploymentService.doStop, ServerService Threads keep in WAITING state waiting all active ejb invocation to finish: > "ServerService Thread Pool -- 116" prio=10 tid=0x00002b5cdce97000 nid=0x6d68 in Object.wait() [0x00002b5d10d0b000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <0x00000005c5447f68> (a java.lang.Object) > at java.lang.Object.wait(Object.java:503) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory.shutdown(ShutDownInterceptorFactory.java:111) > - locked <0x00000005c5447f68> (a java.lang.Object) > at org.jboss.as.ejb3.component.stateless.StatelessSessionComponent.stop(StatelessSessionComponent.java:135) > at org.jboss.as.ee.component.ComponentStartService$2.run(ComponentStartService.java:72) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:724) > at org.jboss.threads.JBossThread.run(JBossThread.java:122) > Locked ownable synchronizers: > - <0x00000005ba6adf98> (a java.util.concurrent.ThreadPoolExecutor$Worker) > However, the application has some managed beans that do long time calls to a EJB method using remote invocation. DC and HC "hang" before the EJB call finish. > JBoss could have a time out to the undeploy. > Version-Release number of selected component (if applicable): > JBoss EAP 6.1.1 > Actual results: > The application does not undeploy intermittently. > DC and HC "hang" (they disconnect to each other) and it is necessary to restart all Hosts. > Expected results: > After some time waiting, the undeploy is forced to finish. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11648) Upgrade to RESTEasy 3.6.3.Final

by Marek Kopecký (Jira)

[ https://issues.jboss.org/browse/WFLY-11648?page=com.atlassian.jira.plugin... ] Marek Kopecký commented on WFLY-11648: -------------------------------------- [Jiras with 3.6.3.Final fix version|https://issues.jboss.org/issues/?jql=project%20%3D%20RESTEASY%20A...] > Upgrade to RESTEasy 3.6.3.Final > ------------------------------- > > Key: WFLY-11648 > URL: https://issues.jboss.org/browse/WFLY-11648 > Project: WildFly > Issue Type: Component Upgrade > Components: REST > Reporter: Marek Kopecký > Assignee: Alessio Soldano > Priority: Critical > > Upgrade to RESTEasy 3.6.3.Final > cc [~jbliznak], [~tterem] -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11648) Upgrade to RESTEasy 3.6.3.Final

by Marek Kopecký (Jira)

Marek Kopecký created WFLY-11648: ------------------------------------ Summary: Upgrade to RESTEasy 3.6.3.Final Key: WFLY-11648 URL: https://issues.jboss.org/browse/WFLY-11648 Project: WildFly Issue Type: Component Upgrade Components: REST Reporter: Marek Kopecký Assignee: Alessio Soldano Upgrade to RESTEasy 3.6.3.Final cc [~jbliznak], [~tterem] -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1187) Embedded server start / stop / start with new --jboss-home continues to refer to previous server.log

by Jean-Francois Denise (Jira)

[ https://issues.jboss.org/browse/WFCORE-1187?page=com.atlassian.jira.plugi... ] Jean-Francois Denise commented on WFCORE-1187: ---------------------------------------------- [~vmarek], you can only use --jboss-home in non modular content (when running cli fat jar). If you built core, you can start CLI that way: java -jar ~/.m2/repository/org/wildfly/core/wildfly-cli/8.0.0.Beta3-SNAPSHOT/wildfly-cli-8.0.0.Beta3-SNAPSHOT-client.jar Otherwise use the jar present in wildfly full: bin/client/jboss-cli-client.jar > Embedded server start / stop / start with new --jboss-home continues to refer to previous server.log > ---------------------------------------------------------------------------------------------------- > > Key: WFCORE-1187 > URL: https://issues.jboss.org/browse/WFCORE-1187 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Ken Wills > Assignee: ehsavoie Hugonnet > Priority: Major > > - start-embedded-server --jboss-home=/foo/bar1 > - stop-embedded-server > - start-embedded-server --jboss-home=/foo/bar2 > -- server.log in /foo/bar1/standalone/logs/server.log is still written to. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3630) NonPersistentIntervalTimerManagementTestCase fails sometimes

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-3630?page=com.atlassian.jira.plugin.... ] Brian Stansberry reassigned WFLY-3630: -------------------------------------- Component/s: EJB (was: Test Suite) Assignee: (was: Jason Greene) > NonPersistentIntervalTimerManagementTestCase fails sometimes > ------------------------------------------------------------ > > Key: WFLY-3630 > URL: https://issues.jboss.org/browse/WFLY-3630 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.0.Alpha1 > Environment: Windows 7 SP1, Oracle JDK 1.7.0_60 > Reporter: Frank Langelage > Priority: Major > > Testcase org.jboss.as.test.integration.ejb.timerservice.mgmt.NonPersistentIntervalTimerManagementTestCase fails sometimes for me when running build with all tests on Windows machine. I never saw this failure on my Solaris box using the same JDK version. And somehow the appearance of the failure seem to be related to the execution time. > Executing the testsuite during the day does not show me this error. Only in the very late evening / early morning hours the error appeared. (All related to Central European Summer time in my case.) > I added some debug output an saw, that, in case of failure, after "activateTimer" the timer fires immediately so that there is one timeout too much then. The initial timeout time of the timer is passed, when it's suspended. When activated it seems to make good for the missed timeout sometimes. > The persistent version of this testcase located in the same package with exactly same logic never fails for me. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2019