[JBoss JIRA] (JBAS-7427) AS won't boot with sun jmx enabled
by Oz Slater (JIRA)
[ https://issues.jboss.org/browse/JBAS-7427?page=com.atlassian.jira.plugin.... ]
Oz Slater commented on JBAS-7427:
---------------------------------
Same issue as Paul Sideleau on JBoss 6.1.0.Final, {jboss.boot.server.log.dir} is not resolving and JBoss literally creating a "${jboss.boot.server.log.dir}" directory to save boot.log. No problem with {jboss.server.log.dir} though.
> AS won't boot with sun jmx enabled
> ----------------------------------
>
> Key: JBAS-7427
> URL: https://issues.jboss.org/browse/JBAS-7427
> Project: Application Server 3 4 5 and 6
> Issue Type: Bug
> Components: Logging
> Environment: sun jdk6, fedora, AS trunk r96005
> Reporter: Jonathan Halliday
> Assignee: David Lloyd
> Fix For: 6.0.0.M2
>
>
> [jhalli jboss-6.0.0-SNAPSHOT]$ export JAVA_OPTS="-Dcom.sun.management.jmxremote.port=12345 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false"
> [jhalli jboss-6.0.0-SNAPSHOT]$ bin/run.sh
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /home/jhalli/IdeaProjects/jboss/jbossas_trunk/build/output/jboss-6.0.0-SNAPSHOT
> JAVA: /usr/local/jdk1.6.0_16/bin/java
> JAVA_OPTS: -Dprogram.name=run.sh -server -Dcom.sun.management.jmxremote.port=12345 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.net.preferIPv4Stack=true
> CLASSPATH: /home/jhalli/IdeaProjects/jboss/jbossas_trunk/build/output/jboss-6.0.0-SNAPSHOT/bin/run.jar:/usr/local/jdk1.6.0_16/lib/tools.jar
> =========================================================================
> Failed to initalize plugin: org.jboss.logging.logmanager.LoggerPluginImpl@214a55f2, cause: java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
> ...
> Failed to initalize plugin: org.jboss.aop.util.logging.SystemOutLoggerPlugin@5c1ae90c, cause: java.lang.AbstractMethodError
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (WFLY-4023) javax.el.ImportHandler#importClass & #importPackage doesn't import WEB-INF/classes
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-4023?page=com.atlassian.jira.plugin.... ]
Farah Juma commented on WFLY-4023:
----------------------------------
[~pgarner] Do you have a reproducer app that you can share?
> javax.el.ImportHandler#importClass & #importPackage doesn't import WEB-INF/classes
> ----------------------------------------------------------------------------------
>
> Key: WFLY-4023
> URL: https://issues.jboss.org/browse/WFLY-4023
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 8.1.0.Final
> Environment: Win7, Wildfly 8.1.0.Final
> Reporter: Patrick Garner
> Assignee: Farah Juma
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> ImportHandler is not importing classes in WEB-INF/classes and, thus, developers are unable to import classes into the EL evaluation environment per EL 3.0 spec. section 1.22.2 "Imports of Packages, Classes, and Static Fields"
> Here's the ImportHandler relevant code (https://github.com/jboss/jboss-el-api_spec/blob/master/src/main/java/java...)
> {code:java}
> private Class<?> getClassFor(String className) {
> if (!notAClass.contains(className)) {
> try {
> return Class.forName(className, false, getClass().getClassLoader());
> } catch (ClassNotFoundException ex) {
> notAClass.add(className);
> }
> }
> return null;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (DROOLS-604) Problems in code generation and parsing when a method is called from Guided Rules Editor
by Abel Marrero Santos (JIRA)
[ https://issues.jboss.org/browse/DROOLS-604?page=com.atlassian.jira.plugin... ]
Abel Marrero Santos updated DROOLS-604:
---------------------------------------
Affects Version/s: 6.2.0.Beta3
> Problems in code generation and parsing when a method is called from Guided Rules Editor
> ----------------------------------------------------------------------------------------
>
> Key: DROOLS-604
> URL: https://issues.jboss.org/browse/DROOLS-604
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final, 6.2.0.Beta1, 6.2.0.Beta2, 6.2.0.Beta3
> Reporter: Abel Marrero Santos
> Assignee: Mark Proctor
> Priority: Critical
> Attachments: model-base-0.0.1-SNAPSHOT.jar
>
>
> I have found a problem in code generation when we use the feature "call a method on <variable>" from the Guided Rule Editor. An InvocationTargetException caused by a ClassCastException is thrown in RuleModelDRLPersistenceImpl.generateSetMethodCallsMethod method.
> I have found other issues that I think are related and that I will try to mention in the comments. I can also provide you with the maven artifact that I'm using.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (WFLY-3683) ScheduledFuture#cancel(boolean) failing to cancel tasks on bean PreDestroy
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-3683?page=com.atlassian.jira.plugin.... ]
Eduardo Martins updated WFLY-3683:
----------------------------------
Comment: was deleted
(was: EE Concurrency RI issue: https://java.net/jira/browse/CU_JAVAEE-6)
> ScheduledFuture#cancel(boolean) failing to cancel tasks on bean PreDestroy
> --------------------------------------------------------------------------
>
> Key: WFLY-3683
> URL: https://issues.jboss.org/browse/WFLY-3683
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 8.1.0.Final
> Reporter: Aaron Cordova
> Assignee: Eduardo Martins
>
> Calls to ScheduledFuture#cancel on bean cleanup are failing to cancel subsequent tasks.
> *NOTE* This only occurs when using the Trigger functionality. I tested the same code with scheduleAtFixedRate, and it works as expected.
> The following bean demonstrates the bug:
> {code:title=Executor.java|borderStyle=solid}
> import java.util.ArrayList;
> import java.util.Collections;
> import java.util.Date;
> import java.util.Iterator;
> import java.util.List;
> import java.util.concurrent.ScheduledFuture;
> import java.util.concurrent.TimeUnit;
> import javax.annotation.PostConstruct;
> import javax.annotation.PreDestroy;
> import javax.annotation.Resource;
> import javax.ejb.Singleton;
> import javax.ejb.Startup;
> import javax.enterprise.concurrent.LastExecution;
> import javax.enterprise.concurrent.ManagedScheduledExecutorService;
> import javax.enterprise.concurrent.Trigger;
> import org.slf4j.Logger;
> import org.slf4j.LoggerFactory;
> /**
> * Session Bean implementation class DataRecorderManagerBean
> */
> @Singleton
> @Startup
> public class ExecutorBug {
> private static final Logger LOGGER = LoggerFactory.getLogger(ExecutorBug.class);
> @Resource
> private ManagedScheduledExecutorService executorService;
> private List<ScheduledFuture<?>> scheduledTasks;
> /**
> * Default constructor.
> */
> public ExecutorBug() {
> }
> @PostConstruct
> void intialize() {
> this.scheduledTasks = Collections.synchronizedList(new ArrayList<ScheduledFuture<?>>());
> // Schedule the device task.
> PeriodicTrigger trigger = new PeriodicTrigger(0, 10, TimeUnit.SECONDS);
> ScheduledFuture<?> future = this.executorService.schedule(new LogRunner(), trigger);
> // Create the scheduled task and add it to the map.
> this.scheduledTasks.add(future);
> }
> @PreDestroy
> void cleanup() {
> // Cancel any scheduled tasks, ensuring that the map is locked.
> synchronized (this.scheduledTasks) {
> Iterator<ScheduledFuture<?>> i = this.scheduledTasks.iterator();
> while (i.hasNext()) {
> ScheduledFuture<?> future = i.next();
> // Cancel the task.
> future.cancel(true);
> }
> }
> this.scheduledTasks.clear();
> this.scheduledTasks = null;
> }
> private class LogRunner implements Runnable {
> public LogRunner() {
> }
> @Override
> public void run() {
> LOGGER.info("I am running");
> }
> }
> private class PeriodicTrigger implements Trigger {
> private final long periodMillis;
> private Date startTime;
> /**
> * Creates and executes a periodic action that becomes enabled first after the given initial delay, and subsequently with the given period; that is executions will commence after initialDelay
> * then initialDelay+period, then initialDelay + 2 * period, and so on.
> *
> * @param initialDelay the time to delay first execution
> * @param period the period between successive executions
> * @param unit the time unit of the initialDelay and period parameters
> */
> public PeriodicTrigger(final long initialDelay, final long period, final TimeUnit unit) {
> this.periodMillis = TimeUnit.MILLISECONDS.convert(period, unit);
> // Calculate the start time.
> Date now = new Date();
> long millis = TimeUnit.MILLISECONDS.convert(initialDelay, unit);
> this.startTime = new Date(now.getTime() + millis);
> }
> @Override
> public Date getNextRunTime(final LastExecution lastExecutionInfo, final Date taskScheduledTime) {
> if (lastExecutionInfo == null) {
> return this.startTime;
> }
> else {
> return new Date(lastExecutionInfo.getScheduledStart().getTime() + this.periodMillis);
> }
> }
> @Override
> public boolean skipRun(final LastExecution lastExecutionInfo, final Date scheduledRunTime) {
> return false;
> }
> }
> }
> {code}
> Steps:
> * Deploy bean in Wildfly 8.1.0-Final using maven deploy goal.
> * Verify log statement is output.
> * Un-deploy bean from admin console.
> *Expected*
> Log statement is no longer called
> *Actual*
> Log statement continues to output after bean is destroyed.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (WFLY-3536) Wildfly 8.1.0 Final keeps established connections forever
by Seth Miller (JIRA)
[ https://issues.jboss.org/browse/WFLY-3536?page=com.atlassian.jira.plugin.... ]
Seth Miller commented on WFLY-3536:
-----------------------------------
Our solution was to update to the 8.2 builds (building our own RPM) so that we can take advantage of the read-timeout as part of the undertow 1.2 schema in standalone.xml, eg:
{code}
<subsystem xmlns="urn:jboss:domain:undertow:1.2">
<server name="default-server" servlet-container="default">
<http-listener name="default" socket-binding="http" buffer-pool="default" tcp-keep-alive="true" read-timeout="60000"/>
...
{code}
Note the undertow schema version (1.2) and the read-timeout setting of 1 minute. This was the default in the version of Tomcat that shipped with Wildfly 7.x. I would like to see this read-timeout value set as the default going forward in Undertow, actually.
I am not aware of a workaround on 8.1; I even tried setting the tcp_keepalive_time at the OS layer.
> Wildfly 8.1.0 Final keeps established connections forever
> ---------------------------------------------------------
>
> Key: WFLY-3536
> URL: https://issues.jboss.org/browse/WFLY-3536
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Environment: Ubuntu on Azure VM using Java-7 or Java-8.
> Reporter: Renan Polo Montebelo
> Assignee: Stuart Douglas
>
> Wildfly 8.1.0 Final seams to keep established TCP connections forever, instead of closing it after the time configured in the IO worker (default 60s). I only noticed this from clients using an Android app, so I guess that their Android App is not behaving well, but Wildfly should be able to handle such situation nicely.
> If I activate "tcp-keep-alive" in /subsystem=undertow/server=default-server/http-listener=default the situation gets a lot better, although it is still not ideal.
> After some 48 hours my Wildfly freezes because there are more than 4K tcp connections established. Seams that only WEB module freezes, because scheduled timers still work (I can see activity in my log). I've checked for TCP connections using netstat -n.
> JBoss Web Server in 7.1.x confirmed not to have this issue. My deployed application is basically JPA / EJB / JAX-RS (Resteasy)
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (WFLY-3536) Wildfly 8.1.0 Final keeps established connections forever
by Susanne Jarl (JIRA)
[ https://issues.jboss.org/browse/WFLY-3536?page=com.atlassian.jira.plugin.... ]
Susanne Jarl commented on WFLY-3536:
------------------------------------
I also face the same problem. I found it impossible to run Wildfly 8.1.0 in production. Previous versions of JBoss were stable for production.
Is there some workaround? When will this be fixed? Is it prioritized at all?
> Wildfly 8.1.0 Final keeps established connections forever
> ---------------------------------------------------------
>
> Key: WFLY-3536
> URL: https://issues.jboss.org/browse/WFLY-3536
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Environment: Ubuntu on Azure VM using Java-7 or Java-8.
> Reporter: Renan Polo Montebelo
> Assignee: Stuart Douglas
>
> Wildfly 8.1.0 Final seams to keep established TCP connections forever, instead of closing it after the time configured in the IO worker (default 60s). I only noticed this from clients using an Android app, so I guess that their Android App is not behaving well, but Wildfly should be able to handle such situation nicely.
> If I activate "tcp-keep-alive" in /subsystem=undertow/server=default-server/http-listener=default the situation gets a lot better, although it is still not ideal.
> After some 48 hours my Wildfly freezes because there are more than 4K tcp connections established. Seams that only WEB module freezes, because scheduled timers still work (I can see activity in my log). I've checked for TCP connections using netstat -n.
> JBoss Web Server in 7.1.x confirmed not to have this issue. My deployed application is basically JPA / EJB / JAX-RS (Resteasy)
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (WFLY-3683) ScheduledFuture#cancel(boolean) failing to cancel tasks on bean PreDestroy
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-3683?page=com.atlassian.jira.plugin.... ]
Eduardo Martins commented on WFLY-3683:
---------------------------------------
EE Concurrency RI issue: https://java.net/jira/browse/CU_JAVAEE-6
> ScheduledFuture#cancel(boolean) failing to cancel tasks on bean PreDestroy
> --------------------------------------------------------------------------
>
> Key: WFLY-3683
> URL: https://issues.jboss.org/browse/WFLY-3683
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 8.1.0.Final
> Reporter: Aaron Cordova
> Assignee: Eduardo Martins
>
> Calls to ScheduledFuture#cancel on bean cleanup are failing to cancel subsequent tasks.
> *NOTE* This only occurs when using the Trigger functionality. I tested the same code with scheduleAtFixedRate, and it works as expected.
> The following bean demonstrates the bug:
> {code:title=Executor.java|borderStyle=solid}
> import java.util.ArrayList;
> import java.util.Collections;
> import java.util.Date;
> import java.util.Iterator;
> import java.util.List;
> import java.util.concurrent.ScheduledFuture;
> import java.util.concurrent.TimeUnit;
> import javax.annotation.PostConstruct;
> import javax.annotation.PreDestroy;
> import javax.annotation.Resource;
> import javax.ejb.Singleton;
> import javax.ejb.Startup;
> import javax.enterprise.concurrent.LastExecution;
> import javax.enterprise.concurrent.ManagedScheduledExecutorService;
> import javax.enterprise.concurrent.Trigger;
> import org.slf4j.Logger;
> import org.slf4j.LoggerFactory;
> /**
> * Session Bean implementation class DataRecorderManagerBean
> */
> @Singleton
> @Startup
> public class ExecutorBug {
> private static final Logger LOGGER = LoggerFactory.getLogger(ExecutorBug.class);
> @Resource
> private ManagedScheduledExecutorService executorService;
> private List<ScheduledFuture<?>> scheduledTasks;
> /**
> * Default constructor.
> */
> public ExecutorBug() {
> }
> @PostConstruct
> void intialize() {
> this.scheduledTasks = Collections.synchronizedList(new ArrayList<ScheduledFuture<?>>());
> // Schedule the device task.
> PeriodicTrigger trigger = new PeriodicTrigger(0, 10, TimeUnit.SECONDS);
> ScheduledFuture<?> future = this.executorService.schedule(new LogRunner(), trigger);
> // Create the scheduled task and add it to the map.
> this.scheduledTasks.add(future);
> }
> @PreDestroy
> void cleanup() {
> // Cancel any scheduled tasks, ensuring that the map is locked.
> synchronized (this.scheduledTasks) {
> Iterator<ScheduledFuture<?>> i = this.scheduledTasks.iterator();
> while (i.hasNext()) {
> ScheduledFuture<?> future = i.next();
> // Cancel the task.
> future.cancel(true);
> }
> }
> this.scheduledTasks.clear();
> this.scheduledTasks = null;
> }
> private class LogRunner implements Runnable {
> public LogRunner() {
> }
> @Override
> public void run() {
> LOGGER.info("I am running");
> }
> }
> private class PeriodicTrigger implements Trigger {
> private final long periodMillis;
> private Date startTime;
> /**
> * Creates and executes a periodic action that becomes enabled first after the given initial delay, and subsequently with the given period; that is executions will commence after initialDelay
> * then initialDelay+period, then initialDelay + 2 * period, and so on.
> *
> * @param initialDelay the time to delay first execution
> * @param period the period between successive executions
> * @param unit the time unit of the initialDelay and period parameters
> */
> public PeriodicTrigger(final long initialDelay, final long period, final TimeUnit unit) {
> this.periodMillis = TimeUnit.MILLISECONDS.convert(period, unit);
> // Calculate the start time.
> Date now = new Date();
> long millis = TimeUnit.MILLISECONDS.convert(initialDelay, unit);
> this.startTime = new Date(now.getTime() + millis);
> }
> @Override
> public Date getNextRunTime(final LastExecution lastExecutionInfo, final Date taskScheduledTime) {
> if (lastExecutionInfo == null) {
> return this.startTime;
> }
> else {
> return new Date(lastExecutionInfo.getScheduledStart().getTime() + this.periodMillis);
> }
> }
> @Override
> public boolean skipRun(final LastExecution lastExecutionInfo, final Date scheduledRunTime) {
> return false;
> }
> }
> }
> {code}
> Steps:
> * Deploy bean in Wildfly 8.1.0-Final using maven deploy goal.
> * Verify log statement is output.
> * Un-deploy bean from admin console.
> *Expected*
> Log statement is no longer called
> *Actual*
> Log statement continues to output after bean is destroyed.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (WFLY-3536) Wildfly 8.1.0 Final keeps established connections forever
by André Justi (JIRA)
[ https://issues.jboss.org/browse/WFLY-3536?page=com.atlassian.jira.plugin.... ]
André Justi commented on WFLY-3536:
-----------------------------------
Any solution? I am facing the same problem!
> Wildfly 8.1.0 Final keeps established connections forever
> ---------------------------------------------------------
>
> Key: WFLY-3536
> URL: https://issues.jboss.org/browse/WFLY-3536
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Environment: Ubuntu on Azure VM using Java-7 or Java-8.
> Reporter: Renan Polo Montebelo
> Assignee: Stuart Douglas
>
> Wildfly 8.1.0 Final seams to keep established TCP connections forever, instead of closing it after the time configured in the IO worker (default 60s). I only noticed this from clients using an Android app, so I guess that their Android App is not behaving well, but Wildfly should be able to handle such situation nicely.
> If I activate "tcp-keep-alive" in /subsystem=undertow/server=default-server/http-listener=default the situation gets a lot better, although it is still not ideal.
> After some 48 hours my Wildfly freezes because there are more than 4K tcp connections established. Seams that only WEB module freezes, because scheduled timers still work (I can see activity in my log). I've checked for TCP connections using netstat -n.
> JBoss Web Server in 7.1.x confirmed not to have this issue. My deployed application is basically JPA / EJB / JAX-RS (Resteasy)
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months