[JBoss JIRA] (WFLY-3683) ScheduledFuture#cancel(boolean) failing to cancel tasks on bean PreDestroy
by Aaron Cordova (JIRA)
Aaron Cordova created WFLY-3683:
-----------------------------------
Summary: 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: Feature Request
Security Level: Public (Everyone can see)
Components: EE
Affects Versions: 8.1.0.Final
Reporter: Aaron Cordova
Assignee: David Lloyd
Calls to ScheduledFuture#cancel on bean cleanup are failing to cancel subsequent tasks.
*NOTE* This only occurs when using the Trigger function. I tested the same code with scheduleAtFixedRate, and it works as expected.
The following bean demonstrates the bug:
{code:title=Executor.java|borderStyle=sold}
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}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3683) ScheduledFuture#cancel(boolean) failing to cancel tasks on bean PreDestroy
by Aaron Cordova (JIRA)
[ https://issues.jboss.org/browse/WFLY-3683?page=com.atlassian.jira.plugin.... ]
Aaron Cordova updated WFLY-3683:
--------------------------------
Description:
Calls to ScheduledFuture#cancel on bean cleanup are failing to cancel subsequent tasks.
*NOTE* This only occurs when using the Trigger function. 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}
was:
Calls to ScheduledFuture#cancel on bean cleanup are failing to cancel subsequent tasks.
*NOTE* This only occurs when using the Trigger function. I tested the same code with scheduleAtFixedRate, and it works as expected.
The following bean demonstrates the bug:
{code:title=Executor.java|borderStyle=sold}
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}
> 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: Feature Request
> Security Level: Public(Everyone can see)
> Components: EE
> Affects Versions: 8.1.0.Final
> Reporter: Aaron Cordova
> Assignee: David Lloyd
>
> Calls to ScheduledFuture#cancel on bean cleanup are failing to cancel subsequent tasks.
> *NOTE* This only occurs when using the Trigger function. 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}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3683) ScheduledFuture#cancel(boolean) failing to cancel tasks on bean PreDestroy
by Aaron Cordova (JIRA)
[ https://issues.jboss.org/browse/WFLY-3683?page=com.atlassian.jira.plugin.... ]
Aaron Cordova updated WFLY-3683:
--------------------------------
Description:
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}
was:
Calls to ScheduledFuture#cancel on bean cleanup are failing to cancel subsequent tasks.
*NOTE* This only occurs when using the Trigger function. 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}
> 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: Feature Request
> Security Level: Public(Everyone can see)
> Components: EE
> Affects Versions: 8.1.0.Final
> Reporter: Aaron Cordova
> Assignee: David Lloyd
>
> 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}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3607) jsr356: OnError always called on page reload
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3607?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-3607:
--------------------------------------
Which version of Wildfly are you testing with? It should be fixed in upstream, but I am not sure if it was also fixed in 8.1.
> jsr356: OnError always called on page reload
> --------------------------------------------
>
> Key: WFLY-3607
> URL: https://issues.jboss.org/browse/WFLY-3607
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Reporter: Jeanfrancois Arcand
> Assignee: Stuart Douglas
> Priority: Minor
>
> When I reload (F5) with Chrome, any jsr356's Handler will be called with
> {noformat}
> 11:24:30,815 ERROR [org.atmosphere.container.JSR356Endpoint] (default I/O-3) : java.nio.channels.ClosedChannelException
> at io.undertow.server.protocol.framed.AbstractFramedChannel.receive(AbstractFramedChannel.java:260)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:20)
> at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:15)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:632)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:618)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> {noformat}
> Tomcat and Jetty won't invoke onError, so I'm curious to learn why Wildfly call onError.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3682) SFSB DistributedCache doesn't commit when get(...) and release/discard(...) use different threads
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-3682:
----------------------------------
Summary: SFSB DistributedCache doesn't commit when get(...) and release/discard(...) use different threads
Key: WFLY-3682
URL: https://issues.jboss.org/browse/WFLY-3682
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: 8.1.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Fix For: 8.2.0.CR1, 9.0.0.CR1
While investigating failures in org.jboss.as.test.manualmode.ejb.client.cluster.EJBClientClusterConfigurationTestCase following the upgrade to JGroups 3.5, I uncovered a number of critical bugs in the DistributedCache logic.
* DistributedCache uses a thread-local stack to store the reference to a Batch across invocations of Cache get/release/discard(...). Consequently, Infinispan's transaction won't commit if Cache.get(...) was called from a different thread than Cache.release(...) or Cache.discard(...)
* The implementation of the Batch SPI uses Infinispan's BatchContainer, which itself relies on thread locals to store references to the Transaction across calls to startBatch()/endBatch().
* Once the above issues were address, I got an NPE in InfinispanBeanEntryExternalizer.writeObject(...) when the lastAccessedTime is null (which is the case following creation).
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-2551) AS7.2 - JMX Datasource pool & jdbc statistics dissapear if you enable validation
by Will Tatam (JIRA)
[ https://issues.jboss.org/browse/WFLY-2551?page=com.atlassian.jira.plugin.... ]
Will Tatam commented on WFLY-2551:
----------------------------------
Good work to trace it. I had spotted it only effected resources that were enabled when jboss booted based on the xml, but hadn't spotted that it was the fact i'm adding disabled and then enabling that was causing the missing items
> AS7.2 - JMX Datasource pool & jdbc statistics dissapear if you enable validation
> --------------------------------------------------------------------------------
>
> Key: WFLY-2551
> URL: https://issues.jboss.org/browse/WFLY-2551
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA, JMX
> Reporter: Will Tatam
> Assignee: Stefano Maestri
>
> If you just create a basic datasource under AS 7.2 the you can view the current statistics about the pool under
> jboss.as:subsystem=datasources,data-source=mySQL,statistics=pool
> However, if you add the following then sometimes the statistics=pool and statistics=jdbc entries disspaear
> <validation><check-valid-connection-sql>select 1</check-valid-connection-sql></validation>
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-2551) AS7.2 - JMX Datasource pool & jdbc statistics dissapear if you enable validation
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-2551?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-2551:
----------------------------------------
The cause of the problem is the way DataSourceStatisticsListener works with the Resource tree. The AbstractDataSourceAdd handler gets a reference to a Resource and then hands it off the DataSourceStatisticsListener. Thereafter that Resource instance has its state modified as the listener reacts to start/stop of the MSC service.
This behavior violates the design of the resource model, which doesn't allow leaking of references to the resource tree outside the control of the ModelController. Any time an operation modifies the resource tree, the entire tree is cloned, and then when the operation commits, that clone is published and made visible to other threads. This copy-on-write/publish-on-commit behavior provides a kind of REPEATABLE_READ semantic -- an op that is changing the model sees its changes, while concurrently executing reads do not see those changes until the first op commits and publishes them.
So, what happens:
1) In step 2 in my previous comment, AbstractDataSourceAdd gets a Resource instance and passes a ref to it to DataSourceStatisticsListener.
2) In step 3, the user invokes an op that writes the model. The result is the resource tree is cloned, and the ref held by DataSourceStatisticsListener is no longer a ref to a part of the current model. (Really, any write op at all, on any resource anywhere would have this effect.)
3) In step 4, the enable op triggers the DataSourceStatisticsListener. This causes the "statistics=jdbc" and "statistics=pool" children to be added to the now out-of-date Resource. This has no effect at all on the official model.
4) The problems seen in steps 5 and 6 are because the official model doesn't show the existence of the "statistics=jdbc" and "statistics=pool" children.
5) The read-resource op in step 7 happens to work because the handler for it is forgiving of the fact that there is no resource for the requested address.
I have thoughts on solutions, which I'll post later.
> AS7.2 - JMX Datasource pool & jdbc statistics dissapear if you enable validation
> --------------------------------------------------------------------------------
>
> Key: WFLY-2551
> URL: https://issues.jboss.org/browse/WFLY-2551
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA, JMX
> Reporter: Will Tatam
> Assignee: Stefano Maestri
>
> If you just create a basic datasource under AS 7.2 the you can view the current statistics about the pool under
> jboss.as:subsystem=datasources,data-source=mySQL,statistics=pool
> However, if you add the following then sometimes the statistics=pool and statistics=jdbc entries disspaear
> <validation><check-valid-connection-sql>select 1</check-valid-connection-sql></validation>
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3368) Reverse proxy configuration should use outbound-socket-binding
by Matt Wringe (JIRA)
[ https://issues.jboss.org/browse/WFLY-3368?page=com.atlassian.jira.plugin.... ]
Matt Wringe commented on WFLY-3368:
-----------------------------------
I havn't looked into this lately, but I think it looks about right :) If you can get me a patch to try out I might be able to do a quick check within the next week or so.
For my usecase, if I tried to specified one particular port than it didn't work due to multiple connections and the socket already being in use (if you don't specify a port than it grabs one from a pool each time). So hopefully the 'port' option there is optional.
> Reverse proxy configuration should use outbound-socket-binding
> --------------------------------------------------------------
>
> Key: WFLY-3368
> URL: https://issues.jboss.org/browse/WFLY-3368
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final
> Reporter: Matt Wringe
> Assignee: Tomaz Cerar
> Fix For: 9.0.0.Beta1
>
>
> The reverse proxy configuration in standalone.xml requires a string value and will not accept variables like most of the other options.
> for example, something like this should be valid, but its currently not:
> {code:xml}
> <handlers>
> <reverse-proxy name="reverse-proxy" connections-per-thread="30">
> <host name="${myURL}" instance-id="myRoute"/>
> </reverse-proxy>
> <handlers>
> {code}
> Here you need to specify the name as something like "http://127.5.183.1:8080"
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-2551) AS7.2 - JMX Datasource pool & jdbc statistics dissapear if you enable validation
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-2551?page=com.atlassian.jira.plugin.... ]
Brian Stansberry edited comment on WFLY-2551 at 7/28/14 5:26 PM:
-----------------------------------------------------------------
I've figured out how to reproduce this and what the underlying issue is. The latter is complex, so first I'll post how to reproduce:
1) Start the system running the standard standalone.xml. Connect jconsole, go to mbeans tab, navigate to jboss.as->datasources->ExampleDS, you'll see "jdbc" and "pool" children.
2) Get the system such that the subsystem has loaded with the datasource disabled. You could edit xml, but here I'll use the CLI against a server started from a standard standalone.xml
{code}
[standalone@localhost:9990 /] cd subsystem=datasources/data-source=ExampleDS
[standalone@localhost:9990 data-source=ExampleDS] :disable
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
[standalone@localhost:9990 data-source=ExampleDS] reload
{code}
3) Change an attribute on the datasource resource. I don't think it much matters which one; check-valid-connection-sql is just the one the reporter was changing:
{code}
[standalone@localhost:9990 data-source=ExampleDS] :write-attribute(name=check-valid-connection-sql,value="select 1")
{"outcome" => "success"}
{code}
4) Enable the datasource
{code}
[standalone@localhost:9990 data-source=ExampleDS] :enable
{"outcome" => "success"}
{code}
5) Close the jconsole connection and reconnect (which refreshes the mbean tree). Under jboss.as->datasources->ExampleDS, you no longer see "jdbc" and "pool" children.
6) Some CLI operations won't work also
{code}
[standalone@localhost:9990 data-source=ExampleDS] cd statistics=jdbc
WFLYCTL0217: Child resource '"statistics" => "jdbc"' not found
[standalone@localhost:9990 data-source=ExampleDS] cd statistics=pool
WFLYCTL0217: Child resource '"statistics" => "pool"' not found
{code}
7) Interestingly, many CLI operations still work, e.g.:
{code}
[standalone@localhost:9990 data-source=ExampleDS] ./statistics=jdbc:read-resource(include-runtime=true)
{
"outcome" => "success",
"result" => {
"PreparedStatementCacheAccessCount" => "0",
"PreparedStatementCacheAddCount" => "0",
"PreparedStatementCacheCurrentSize" => "0",
"PreparedStatementCacheDeleteCount" => "0",
"PreparedStatementCacheHitCount" => "0",
"PreparedStatementCacheMissCount" => "0",
"statistics-enabled" => false
}
}
{code}
The reason for this is just that the handler for "read-resource" happens to be forgiving of the underlying problem, which I'll get to next.
was (Author: brian.stansberry):
I've figured out how to reproduce this and what the underlying issue is. The latter is complex, so first I'll post how to reproduce:
1) Start the system running the standard standalone.xml. Connect jconsole, go to mbeans tab, navigate to jboss.as->datasources->ExampleDS, you'll see "jdbc" and "pool" children.
2) Get the system such that the subsystem has loaded with the datasource disabled. You could edit xml, but here I'll use the CLI against a server started from a standard standalone.xml
{code}
[standalone@localhost:9990 /] cd subsystem=datasources/data-source=ExampleDS
[standalone@localhost:9990 data-source=ExampleDS] :disable
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
[standalone@localhost:9990 data-source=ExampleDS] reload
{code}
2) Change an attribute on the datasource resource. I don't think it much matters which one; check-valid-connection-sql is just the one the reporter was changing:
{code}
[standalone@localhost:9990 data-source=ExampleDS] :write-attribute(name=check-valid-connection-sql,value="select 1")
{"outcome" => "success"}
{code}
3) Enable the datasource
{code}
[standalone@localhost:9990 data-source=ExampleDS] :enable
{"outcome" => "success"}
{code}
4) Close the jconsole connection and reconnect (which refreshes the mbean tree). Under jboss.as->datasources->ExampleDS, you no longer see "jdbc" and "pool" children.
5) Some CLI operations won't work also
{code}
[standalone@localhost:9990 data-source=ExampleDS] cd statistics=jdbc
WFLYCTL0217: Child resource '"statistics" => "jdbc"' not found
[standalone@localhost:9990 data-source=ExampleDS] cd statistics=pool
WFLYCTL0217: Child resource '"statistics" => "pool"' not found
{code}
6) Interestingly, many CLI operations still work, e.g.:
{code}
[standalone@localhost:9990 data-source=ExampleDS] ./statistics=jdbc:read-resource(include-runtime=true)
{
"outcome" => "success",
"result" => {
"PreparedStatementCacheAccessCount" => "0",
"PreparedStatementCacheAddCount" => "0",
"PreparedStatementCacheCurrentSize" => "0",
"PreparedStatementCacheDeleteCount" => "0",
"PreparedStatementCacheHitCount" => "0",
"PreparedStatementCacheMissCount" => "0",
"statistics-enabled" => false
}
}
{code}
The reason for this is just that the handler for "read-resource" happens to be forgiving of the underlying problem, which I'll get to next.
> AS7.2 - JMX Datasource pool & jdbc statistics dissapear if you enable validation
> --------------------------------------------------------------------------------
>
> Key: WFLY-2551
> URL: https://issues.jboss.org/browse/WFLY-2551
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA, JMX
> Reporter: Will Tatam
> Assignee: Stefano Maestri
>
> If you just create a basic datasource under AS 7.2 the you can view the current statistics about the pool under
> jboss.as:subsystem=datasources,data-source=mySQL,statistics=pool
> However, if you add the following then sometimes the statistics=pool and statistics=jdbc entries disspaear
> <validation><check-valid-connection-sql>select 1</check-valid-connection-sql></validation>
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-2551) AS7.2 - JMX Datasource pool & jdbc statistics dissapear if you enable validation
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-2551?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-2551:
----------------------------------------
I've figured out how to reproduce this and what the underlying issue is. The latter is complex, so first I'll post how to reproduce:
1) Start the system running the standard standalone.xml. Connect jconsole, go to mbeans tab, navigate to jboss.as->datasources->ExampleDS, you'll see "jdbc" and "pool" children.
2) Get the system such that the subsystem has loaded with the datasource disabled. You could edit xml, but here I'll use the CLI against a server started from a standard standalone.xml
{code}
[standalone@localhost:9990 /] cd subsystem=datasources/data-source=ExampleDS
[standalone@localhost:9990 data-source=ExampleDS] :disable
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
[standalone@localhost:9990 data-source=ExampleDS] reload
{code}
2) Change an attribute on the datasource resource. I don't think it much matters which one; check-valid-connection-sql is just the one the reporter was changing:
{code}
[standalone@localhost:9990 data-source=ExampleDS] :write-attribute(name=check-valid-connection-sql,value="select 1")
{"outcome" => "success"}
{code}
3) Enable the datasource
{code}
[standalone@localhost:9990 data-source=ExampleDS] :enable
{"outcome" => "success"}
{code}
4) Close the jconsole connection and reconnect (which refreshes the mbean tree). Under jboss.as->datasources->ExampleDS, you no longer see "jdbc" and "pool" children.
5) Some CLI operations won't work also
{code}
[standalone@localhost:9990 data-source=ExampleDS] cd statistics=jdbc
WFLYCTL0217: Child resource '"statistics" => "jdbc"' not found
[standalone@localhost:9990 data-source=ExampleDS] cd statistics=pool
WFLYCTL0217: Child resource '"statistics" => "pool"' not found
{code}
6) Interestingly, many CLI operations still work, e.g.:
{code}
[standalone@localhost:9990 data-source=ExampleDS] ./statistics=jdbc:read-resource(include-runtime=true)
{
"outcome" => "success",
"result" => {
"PreparedStatementCacheAccessCount" => "0",
"PreparedStatementCacheAddCount" => "0",
"PreparedStatementCacheCurrentSize" => "0",
"PreparedStatementCacheDeleteCount" => "0",
"PreparedStatementCacheHitCount" => "0",
"PreparedStatementCacheMissCount" => "0",
"statistics-enabled" => false
}
}
{code}
The reason for this is just that the handler for "read-resource" happens to be forgiving of the underlying problem, which I'll get to next.
> AS7.2 - JMX Datasource pool & jdbc statistics dissapear if you enable validation
> --------------------------------------------------------------------------------
>
> Key: WFLY-2551
> URL: https://issues.jboss.org/browse/WFLY-2551
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA, JMX
> Reporter: Will Tatam
> Assignee: Stefano Maestri
>
> If you just create a basic datasource under AS 7.2 the you can view the current statistics about the pool under
> jboss.as:subsystem=datasources,data-source=mySQL,statistics=pool
> However, if you add the following then sometimes the statistics=pool and statistics=jdbc entries disspaear
> <validation><check-valid-connection-sql>select 1</check-valid-connection-sql></validation>
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months