[JBoss JIRA] (LOGMGR-119) Wrong backup file names by PeriodicRotatingFileHandler when suffix "yyyy-ww"
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-119?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated LOGMGR-119:
-------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1171020
> Wrong backup file names by PeriodicRotatingFileHandler when suffix "yyyy-ww"
> ----------------------------------------------------------------------------
>
> Key: LOGMGR-119
> URL: https://issues.jboss.org/browse/LOGMGR-119
> Project: JBoss Log Manager
> Issue Type: Bug
> Affects Versions: 1.5.2.Final
> Reporter: Osamu Nagano
> Assignee: James Perkins
>
> When {{PeriodicRotatingFileHandler}} with suffix "yyyy-ww" rotates a log file over a year, file that belongs to the new year is incorrectly named using the previous year.
> Here is a demonstrating test code supposed to be pasted into {{src/test/java/org/jboss/logmanager/handlers/PeriodicSizeRotatingFileHandlerTests.java}}. It mimics a record started from 2014-12-24 and the resulting backup log file is named {{rotating-file-handler.log.2014-01}}. It should be 2015 instead.
> {code}
> /*
> * Run with the following command:
> * mvn compile test -Dtest=PeriodicSizeRotatingFileHandlerTests#testPeriodicRotateWeekOfYear
> */
> @Test
> public void testPeriodicRotateWeekOfYear() throws Exception {
> SimpleDateFormat fmt = periodFormatMap.get(Calendar.WEEK_OF_YEAR);
> Calendar cal = Calendar.getInstance(java.util.TimeZone.getTimeZone("GMT"));
>
> PeriodicRotatingFileHandler handler = new PeriodicRotatingFileHandler();
> handler.setAutoFlush(true);
> handler.setFormatter(new PatternFormatter("%d{yyyy-MM-dd HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"));
> handler.setSuffix("." + fmt.toPattern());
> handler.setFile(logFile);
>
> cal.set(Calendar.YEAR, 2014);
> cal.set(Calendar.MONTH, 12 - 1);
> cal.set(Calendar.DAY_OF_MONTH, 24);
> cal.set(Calendar.HOUR_OF_DAY, 12);
>
> for (int i = 0; i < 14; i++) {
> long tim = cal.getTimeInMillis();
> String fdate = fmt.format(tim);
> ExtLogRecord record = createLogRecord("%02d th formatted date is %s", i, fdate);
> record.setMillis(tim);
> handler.publish(record);
>
> cal.add(Calendar.DAY_OF_MONTH, 1);
> }
>
> handler.close();
>
> for (String logFile : BASE_LOG_DIR.list()) {
> System.out.println(logFile);
> }
> Assert.assertTrue("Dummy.", true);
> }
> {code}
> And here is the result of the test method.
> {code}
> % ll logs
> total 12K
> -rw-r--r--. 1 onagano onagano 228 Dec 5 17:09 rotating-file-handler.log
> -rw-r--r--. 1 onagano onagano 532 Dec 5 17:09 rotating-file-handler.log.2014-01
> -rw-r--r--. 1 onagano onagano 0 Dec 5 17:09 rotating-file-handler.log.2014-49
> -rw-r--r--. 1 onagano onagano 304 Dec 5 17:09 rotating-file-handler.log.2014-52
> % cat logs/rotating-file-handler.log.2014-52
> 2014-12-24 21:09:43,921 INFO [null] (main) 00 th formatted date is 2014-52
> 2014-12-25 21:09:43,921 INFO [null] (main) 01 th formatted date is 2014-52
> 2014-12-26 21:09:43,921 INFO [null] (main) 02 th formatted date is 2014-52
> 2014-12-27 21:09:43,921 INFO [null] (main) 03 th formatted date is 2014-52
> % cat logs/rotating-file-handler.log.2014-01
> 2014-12-28 21:09:43,921 INFO [null] (main) 04 th formatted date is 2014-01
> 2014-12-29 21:09:43,921 INFO [null] (main) 05 th formatted date is 2014-01
> 2014-12-30 21:09:43,921 INFO [null] (main) 06 th formatted date is 2014-01
> 2014-12-31 21:09:43,921 INFO [null] (main) 07 th formatted date is 2014-01
> 2015-01-01 21:09:43,921 INFO [null] (main) 08 th formatted date is 2015-01
> 2015-01-02 21:09:43,921 INFO [null] (main) 09 th formatted date is 2015-01
> 2015-01-03 21:09:43,921 INFO [null] (main) 10 th formatted date is 2015-01
> % cat logs/rotating-file-handler.log
> 2015-01-04 21:09:43,921 INFO [null] (main) 11 th formatted date is 2015-02
> 2015-01-05 21:09:43,921 INFO [null] (main) 12 th formatted date is 2015-02
> 2015-01-06 21:09:43,921 INFO [null] (main) 13 th formatted date is 2015-02
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 10 months
[JBoss JIRA] (LOGMGR-119) Wrong backup file names by PeriodicRotatingFileHandler when suffix "yyyy-ww"
by Osamu Nagano (JIRA)
Osamu Nagano created LOGMGR-119:
-----------------------------------
Summary: Wrong backup file names by PeriodicRotatingFileHandler when suffix "yyyy-ww"
Key: LOGMGR-119
URL: https://issues.jboss.org/browse/LOGMGR-119
Project: JBoss Log Manager
Issue Type: Bug
Affects Versions: 1.5.2.Final
Reporter: Osamu Nagano
Assignee: James Perkins
When {{PeriodicRotatingFileHandler}} with suffix "yyyy-ww" rotates a log file over a year, file that belongs to the new year is incorrectly named using the previous year.
Here is a demonstrating test code supposed to be pasted into {{src/test/java/org/jboss/logmanager/handlers/PeriodicSizeRotatingFileHandlerTests.java}}. It mimics a record started from 2014-12-24 and the resulting backup log file is named {{rotating-file-handler.log.2014-01}}. It should be 2015 instead.
{code}
/*
* Run with the following command:
* mvn compile test -Dtest=PeriodicSizeRotatingFileHandlerTests#testPeriodicRotateWeekOfYear
*/
@Test
public void testPeriodicRotateWeekOfYear() throws Exception {
SimpleDateFormat fmt = periodFormatMap.get(Calendar.WEEK_OF_YEAR);
Calendar cal = Calendar.getInstance(java.util.TimeZone.getTimeZone("GMT"));
PeriodicRotatingFileHandler handler = new PeriodicRotatingFileHandler();
handler.setAutoFlush(true);
handler.setFormatter(new PatternFormatter("%d{yyyy-MM-dd HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"));
handler.setSuffix("." + fmt.toPattern());
handler.setFile(logFile);
cal.set(Calendar.YEAR, 2014);
cal.set(Calendar.MONTH, 12 - 1);
cal.set(Calendar.DAY_OF_MONTH, 24);
cal.set(Calendar.HOUR_OF_DAY, 12);
for (int i = 0; i < 14; i++) {
long tim = cal.getTimeInMillis();
String fdate = fmt.format(tim);
ExtLogRecord record = createLogRecord("%02d th formatted date is %s", i, fdate);
record.setMillis(tim);
handler.publish(record);
cal.add(Calendar.DAY_OF_MONTH, 1);
}
handler.close();
for (String logFile : BASE_LOG_DIR.list()) {
System.out.println(logFile);
}
Assert.assertTrue("Dummy.", true);
}
{code}
And here is the result of the test method.
{code}
% ll logs
total 12K
-rw-r--r--. 1 onagano onagano 228 Dec 5 17:09 rotating-file-handler.log
-rw-r--r--. 1 onagano onagano 532 Dec 5 17:09 rotating-file-handler.log.2014-01
-rw-r--r--. 1 onagano onagano 0 Dec 5 17:09 rotating-file-handler.log.2014-49
-rw-r--r--. 1 onagano onagano 304 Dec 5 17:09 rotating-file-handler.log.2014-52
% cat logs/rotating-file-handler.log.2014-52
2014-12-24 21:09:43,921 INFO [null] (main) 00 th formatted date is 2014-52
2014-12-25 21:09:43,921 INFO [null] (main) 01 th formatted date is 2014-52
2014-12-26 21:09:43,921 INFO [null] (main) 02 th formatted date is 2014-52
2014-12-27 21:09:43,921 INFO [null] (main) 03 th formatted date is 2014-52
% cat logs/rotating-file-handler.log.2014-01
2014-12-28 21:09:43,921 INFO [null] (main) 04 th formatted date is 2014-01
2014-12-29 21:09:43,921 INFO [null] (main) 05 th formatted date is 2014-01
2014-12-30 21:09:43,921 INFO [null] (main) 06 th formatted date is 2014-01
2014-12-31 21:09:43,921 INFO [null] (main) 07 th formatted date is 2014-01
2015-01-01 21:09:43,921 INFO [null] (main) 08 th formatted date is 2015-01
2015-01-02 21:09:43,921 INFO [null] (main) 09 th formatted date is 2015-01
2015-01-03 21:09:43,921 INFO [null] (main) 10 th formatted date is 2015-01
% cat logs/rotating-file-handler.log
2015-01-04 21:09:43,921 INFO [null] (main) 11 th formatted date is 2015-02
2015-01-05 21:09:43,921 INFO [null] (main) 12 th formatted date is 2015-02
2015-01-06 21:09:43,921 INFO [null] (main) 13 th formatted date is 2015-02
{code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 10 months
[JBoss JIRA] (WFLY-4008) MBean deployment causes javax.naming.NameNotFoundException: java:comp/BeanManager
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/WFLY-4008?page=com.atlassian.jira.plugin.... ]
Amos Feng commented on WFLY-4008:
---------------------------------
I thinks I find the root clause of this issue. There are two action in the setupActions: org.jboss.as.ee.naming.JavaNamespaceSetup and org.jboss.as.weld.arquillian.WeldContextSetup. When the following codes run in MBeanRegistrationService.java
{code}
public synchronized void start(final StartContext context) throws StartException {
final MBeanServer mBeanServer = getMBeanServer();
final T value = this.value.getValue();
try {
objectName = new ObjectName(name);
} catch (MalformedObjectNameException e) {
throw JmxLogger.ROOT_LOGGER.mbeanRegistrationFailed(e, name);
}
try {
for (SetupAction action : setupActions) {
action.setup(Collections.<String, Object>emptyMap());
}
try {
ROOT_LOGGER.debugf("Registering [%s] with name [%s]", value, objectName);
mBeanServer.registerMBean(value, objectName);
} catch (Exception e) {
throw ROOT_LOGGER.mbeanRegistrationFailed(e, name);
}
} finally {
for (SetupAction action : setupActions) {
action.teardown(Collections.<String, Object>emptyMap());
}
}
}
{code}
The JavaNamespaceSetup teardown happens before the WeldContextSetup so it throws NameNotFound Exception in the WeldContextSetup teardown.
The possible fix is to reverse the setupActions before running the teardown method.
> MBean deployment causes javax.naming.NameNotFoundException: java:comp/BeanManager
> ----------------------------------------------------------------------------------
>
> Key: WFLY-4008
> URL: https://issues.jboss.org/browse/WFLY-4008
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, JMX, Naming
> Affects Versions: 8.1.0.Final
> Reporter: Darryl Miles
> Assignee: Stuart Douglas
> Labels: mbean
>
> If you create an MBean in your EJB and deploy the EJB.
> <pre>
> @SuppressWarnings("serial")
> public class Monitor implements MonitorMXBean, Serializable {
> private static final Logger log = LoggerFactory.getLogger(Monitor.class);
> private Boolean enabled = Boolean.FALSE;
> private Long valueOne;
> public Monitor() {
> log.debug("CTOR");
> }
> @Override
> public Boolean isEnabled() {
> return enabled;
> }
> @Override
> public void setEnabled(Boolean enabled) {
> this.enabled = enabled;
> }
> @Override
> public Long getValueOne() {
> return valueOne;
> }
> @Override
> public void setValueOne(Long valueOne) {
> this.valueOne = valueOne;
> }
> }
> </pre>
> And JMX MXBean
> <pre>
> import javax.management.MXBean;
> @MXBean
> public interface MonitorMXBean {
> void setEnabled(Boolean enabled);
> Boolean isEnabled();
> void setValueOne(Long valueOne);
> Long getValueOne();
> }
> </pre>
> 17:34:42,455 ERROR [org.jboss.as.weld] (MSC service thread 1-1) JBAS016001: Failed to tear down Weld contexts: javax.naming.NameNotFoundException: java:comp/BeanManager
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.findContext(InitialContext.java:187)
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:231)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
> at javax.naming.InitialContext.lookup(InitialContext.java:417) [rt.jar:1.8.0_25]
> at javax.naming.InitialContext.lookup(InitialContext.java:417) [rt.jar:1.8.0_25]
> at org.jboss.as.weld.arquillian.WeldContextSetup.teardown(WeldContextSetup.java:108)
> at org.jboss.as.jmx.MBeanRegistrationService.stop(MBeanRegistrationService.java:132) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_25]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25]
> Is this related to: https://issues.jboss.org/browse/WFLY-822 ?
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 10 months
[JBoss JIRA] (WFLY-4158) The task-keepalive property in the domain:io subsystem is ignored causing an async servlet timeout at 30 seconds
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-4158?page=com.atlassian.jira.plugin.... ]
Jason Greene reassigned WFLY-4158:
----------------------------------
Assignee: Tomaz Cerar (was: Jason Greene)
> The task-keepalive property in the domain:io subsystem is ignored causing an async servlet timeout at 30 seconds
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4158
> URL: https://issues.jboss.org/browse/WFLY-4158
> Project: WildFly
> Issue Type: Bug
> Components: IO
> Affects Versions: 8.2.0.Final
> Environment: Windows Server 2008, Windows 7, Java SE 7u72 and 8u25 64bit
> Reporter: Raul Guerrero Deschamps
> Assignee: Tomaz Cerar
> Labels: asynchronous, servlet, timeout
>
> I have a file upload and download asynchronous servlet, I define a ReadListener and WriteListener to process the files.
> To be able to handle really large files, I setted a property in the IO subsystem to have the IO thread timeout at one hour using the task-keepalive property to avoid leaked threads if the request has a problem:
> <subsystem xmlns="urn:jboss:domain:io:1.1">
> <worker name="default" task-keepalive="3600"/>
> <buffer-pool name="default"/>
> </subsystem>
> And also set the max-post-size property to the maximum to avoid limiting the size of the file, so you can upload files of any size as long as it only takes one hour, this is an intranet application so we don't have bandwidth issues or timeouts for the uploads and downloads.
> <subsystem xmlns="urn:jboss:domain:undertow:1.2">
> <buffer-cache name="default"/>
> <server name="default-server">
> <http-listener name="default" socket-binding="http" max-post-size="0"/>
> ...
> Now, this works perfectly on WildFly 8.1.0 Final, but I upgraded to 8.2.0, and even though I setted the same properties, I get an exception exactly at 30 seconds after a request for an upload or download:
> ERROR [io.undertow.request] (default task-32) Undertow request failed HttpServerExchange{ PUT /xxx/file}: java.lang.NullPointerException
> Followed by:
> ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception
> Which is what happens when an I/O thread times out, so it causes the NullPointerException in the servlet because the IO thread is gone.
> Even though I set any time on the task-keepalive property, still the IO thread gets always killed at 30 seconds.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 10 months
[JBoss JIRA] (WFLY-4072) Unable to Enable JTA for a Datasource
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/WFLY-4072?page=com.atlassian.jira.plugin.... ]
Stefano Maestri commented on WFLY-4072:
---------------------------------------
Could you provide me some more context please.
Attach your configuration (standalone/domain.xml should be fine) and how are you trying to enable JTA (via cli/webconsole whatever?)
> Unable to Enable JTA for a Datasource
> -------------------------------------
>
> Key: WFLY-4072
> URL: https://issues.jboss.org/browse/WFLY-4072
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 8.1.0.Final
> Environment: Windows 7
> Java 8u25
> WildFly 8.1.0.Final
> Reporter: shinzey shinzey
> Assignee: Stefano Maestri
> Priority: Critical
> Labels: Datasource, JTA, ejb, wildfly
>
> Whenever trying to enable JTA, the following error is reported:
> Unknown error
> Unexpected HTTP response: 500
> Request
> {
> "name" => "test",
> "user-name" => "test",
> "password" => "test",
> "security-domain" => "",
> "jndi-name" => "java:/datasource/test",
> "transaction-isolation" => "TRANSACTION_READ_COMMITTED",
> "new-connection-sql" => "",
> "connection-url" => "jdbc:derby://localhost:1527/test",
> "driver-class" => "org.apache.derby.jdbc.ClientDriver",
> "jta" => true,
> "pool-name" => "",
> "use-ccm" => false,
> "datasource-class" => "",
> "valid-connection-checker-class-name" => "",
> "check-valid-connection-sql" => "",
> "background-validation" => false,
> "background-validation-millis" => -1L,
> "validate-on-match" => false,
> "stale-connection-checker-class-name" => "",
> "exception-sorter-class-name" => "",
> "prepared-statements-cache-size" => -1L,
> "share-prepared-statements" => false,
> "enabled" => false,
> "driver-name" => "Derby_org.apache.derby.jdbc.ClientDriver_10_10",
> "operation" => "enable",
> "address" => [
> ("subsystem" => "datasources"),
> ("data-source" => "test")
> ]
> }
> Response
> Internal Server Error
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014750: Operation handler failed to complete",
> "rolled-back" => true
> }
> Due to this issue, EJB's transaction management does not work. I tested the same database on GlassFish and JTA works fine.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 10 months
[JBoss JIRA] (WFLY-2986) cli batch incorrect handling of the enabled attribute during datasource creation
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/WFLY-2986?page=com.atlassian.jira.plugin.... ]
Stefano Maestri resolved WFLY-2986.
-----------------------------------
Resolution: Won't Fix
It's happening because adding a datasource w/ enabled==true is in fact creating a composite operation in which second step is :enable and it's executed in Model.STAGE, so after :disable operation of the batch.
After all is a non sense create a batch adding a datasource w/ enabled==true and the :disable it in the same batch. Just create it w/ enabled==false.
So I'm closing this issue as won't fix
> cli batch incorrect handling of the enabled attribute during datasource creation
> --------------------------------------------------------------------------------
>
> Key: WFLY-2986
> URL: https://issues.jboss.org/browse/WFLY-2986
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, JCA
> Affects Versions: 8.0.0.Final
> Environment: win 7 pro sp2
> wildfly 8.0.0.Final
> Reporter: Gabriele Garuglieri
> Assignee: Stefano Maestri
>
> case:
> /subsystem=datasources/data-source=xxxxxx:add(....) (without declaring enabled attribute)
> the ds is created with enabled=true, consistent with xsd default, but after WFLY-86 shouldn't it default to false when omitted ?
> /subsystem=datasources/data-source=xxxxxx:add(...., enabled=true)
> the ds is created with enabled=true as requested
> but in both cases the operation
> /subsystem=datasources/data-source=xxxxxx:disable
> WITHIN THE SAME BATCH is happily ignored, ie the final outcome is success but the state of the created ds is still enabled.
> The opposite instead works, adding the ds with enabled=false produces a disabled ds and adding
> /subsystem=datasources/data-source=xxxxxx:enable
> within the same batch, produces an enabled ds.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 10 months
[JBoss JIRA] (WFLY-4158) The task-keepalive property in the domain:io subsystem is ignored causing an async servlet timeout at 30 seconds
by Raul Guerrero Deschamps (JIRA)
[ https://issues.jboss.org/browse/WFLY-4158?page=com.atlassian.jira.plugin.... ]
Raul Guerrero Deschamps updated WFLY-4158:
------------------------------------------
Description:
I have a file upload and download asynchronous servlet, I define a ReadListener and WriteListener to process the files.
To be able to handle really large files, I setted a property in the IO subsystem to have the IO thread timeout at one hour using the task-keepalive property to avoid leaked threads if the request has a problem:
<subsystem xmlns="urn:jboss:domain:io:1.1">
<worker name="default" task-keepalive="3600"/>
<buffer-pool name="default"/>
</subsystem>
And also set the max-post-size property to the maximum to avoid limiting the size of the file, so you can upload files of any size as long as it only takes one hour, this is an intranet application so we don't have bandwidth issues or timeouts for the uploads and downloads.
<subsystem xmlns="urn:jboss:domain:undertow:1.2">
<buffer-cache name="default"/>
<server name="default-server">
<http-listener name="default" socket-binding="http" max-post-size="0"/>
...
Now, this works perfectly on WildFly 8.1.0 Final, but I upgraded to 8.2.0, and even though I setted the same properties, I get an exception exactly at 30 seconds after a request for an upload or download:
ERROR [io.undertow.request] (default task-32) Undertow request failed HttpServerExchange{ PUT /xxx/file}: java.lang.NullPointerException
Followed by:
ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception
Which is what happens when an I/O thread times out, so it causes the NullPointerException in the servlet because the IO thread is gone.
Even though I set any time on the task-keepalive property, still the IO thread gets always killed at 30 seconds.
was:
I have a file upload and download asynchronous servlet, I define a ReadListener and WriteListener to process the files.
To be able to handle really large files, I setted a property in the IO subsystem to have the IO thread timeout at one hour to avoid leaked threads if the request has a problem:
<subsystem xmlns="urn:jboss:domain:io:1.1">
<worker name="default" task-keepalive="3600"/>
<buffer-pool name="default"/>
</subsystem>
And also set the max-post-size property to the maximum to avoid limiting the size of the file, so you can upload files of any size as long as it only takes one hour, this is an intranet application so we don't have bandwidth issues or timeouts for the uploads and downloads.
<subsystem xmlns="urn:jboss:domain:undertow:1.2">
<buffer-cache name="default"/>
<server name="default-server">
<http-listener name="default" socket-binding="http" max-post-size="0"/>
...
Now, this works perfectly on WildFly 8.1.0 Final, but I upgraded to 8.2.0, and even though I setted the same properties, I get an exception exactly at 30 seconds after a request for an upload or download:
ERROR [io.undertow.request] (default task-32) Undertow request failed HttpServerExchange{ PUT /xxx/file}: java.lang.NullPointerException
Followed by:
ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception
Which is what happens when an I/O thread times out, so it causes the NullPointerException in the servlet because the IO thread is gone.
Even though I set any time on the task-keepalive property, still the IO thread gets always killed at 30 seconds.
> The task-keepalive property in the domain:io subsystem is ignored causing an async servlet timeout at 30 seconds
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4158
> URL: https://issues.jboss.org/browse/WFLY-4158
> Project: WildFly
> Issue Type: Bug
> Components: IO
> Affects Versions: 8.2.0.Final
> Environment: Windows Server 2008, Windows 7, Java SE 7u72 and 8u25 64bit
> Reporter: Raul Guerrero Deschamps
> Assignee: Jason Greene
> Labels: asynchronous, servlet, timeout
>
> I have a file upload and download asynchronous servlet, I define a ReadListener and WriteListener to process the files.
> To be able to handle really large files, I setted a property in the IO subsystem to have the IO thread timeout at one hour using the task-keepalive property to avoid leaked threads if the request has a problem:
> <subsystem xmlns="urn:jboss:domain:io:1.1">
> <worker name="default" task-keepalive="3600"/>
> <buffer-pool name="default"/>
> </subsystem>
> And also set the max-post-size property to the maximum to avoid limiting the size of the file, so you can upload files of any size as long as it only takes one hour, this is an intranet application so we don't have bandwidth issues or timeouts for the uploads and downloads.
> <subsystem xmlns="urn:jboss:domain:undertow:1.2">
> <buffer-cache name="default"/>
> <server name="default-server">
> <http-listener name="default" socket-binding="http" max-post-size="0"/>
> ...
> Now, this works perfectly on WildFly 8.1.0 Final, but I upgraded to 8.2.0, and even though I setted the same properties, I get an exception exactly at 30 seconds after a request for an upload or download:
> ERROR [io.undertow.request] (default task-32) Undertow request failed HttpServerExchange{ PUT /xxx/file}: java.lang.NullPointerException
> Followed by:
> ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception
> Which is what happens when an I/O thread times out, so it causes the NullPointerException in the servlet because the IO thread is gone.
> Even though I set any time on the task-keepalive property, still the IO thread gets always killed at 30 seconds.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 10 months
[JBoss JIRA] (WFLY-4158) The task-keepalive property in the domain:io subsystem is ignored causing an async servlet timeout at 30 seconds
by Raul Guerrero Deschamps (JIRA)
Raul Guerrero Deschamps created WFLY-4158:
---------------------------------------------
Summary: The task-keepalive property in the domain:io subsystem is ignored causing an async servlet timeout at 30 seconds
Key: WFLY-4158
URL: https://issues.jboss.org/browse/WFLY-4158
Project: WildFly
Issue Type: Bug
Components: IO
Affects Versions: 8.2.0.Final
Environment: Windows Server 2008, Windows 7, Java SE 7u72 and 8u25 64bit
Reporter: Raul Guerrero Deschamps
Assignee: Jason Greene
I have a file upload and download asynchronous servlet, I define a ReadListener and WriteListener to process the files.
To be able to handle really large files, I setted a property in the IO subsystem to have the IO thread timeout at one hour to avoid leaked threads if the request has a problem:
<subsystem xmlns="urn:jboss:domain:io:1.1">
<worker name="default" task-keepalive="3600"/>
<buffer-pool name="default"/>
</subsystem>
And also set the max-post-size property to the maximum to avoid limiting the size of the file, so you can upload files of any size as long as it only takes one hour, this is an intranet application so we don't have bandwidth issues or timeouts for the uploads and downloads.
<subsystem xmlns="urn:jboss:domain:undertow:1.2">
<buffer-cache name="default"/>
<server name="default-server">
<http-listener name="default" socket-binding="http" max-post-size="0"/>
...
Now, this works perfectly on WildFly 8.1.0 Final, but I upgraded to 8.2.0, and even though I setted the same properties, I get an exception exactly at 30 seconds after a request for an upload or download:
ERROR [io.undertow.request] (default task-32) Undertow request failed HttpServerExchange{ PUT /xxx/file}: java.lang.NullPointerException
Followed by:
ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception
Which is what happens when an I/O thread times out, so it causes the NullPointerException in the servlet because the IO thread is gone.
Even though I set any time on the task-keepalive property, still the IO thread gets always killed at 30 seconds.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 10 months