[JBoss JIRA] (REMJMX-102) Remoting JMX closing Remoting Endpoint before all tasks complete
by Brad Maxwell (JIRA)
Brad Maxwell created REMJMX-102:
-----------------------------------
Summary: Remoting JMX closing Remoting Endpoint before all tasks complete
Key: REMJMX-102
URL: https://issues.jboss.org/browse/REMJMX-102
Project: Remoting JMX
Issue Type: Bug
Reporter: Brad Maxwell
Assignee: Darran Lofthouse
Remoting JMX closing Remoting Endpoint before all tasks are complete resulting in:
{code}
2015-03-29 05:00:54,513 TRACE [Collectd-Thread-33-of-150] org.jboss.remoting.endpoint: Allocated tick to 2 of endpoint "endpoint" <7d484721> (opened Connection to /10.64.67.65:9999)
2015-03-29 05:00:54,528 TRACE [Remoting "endpoint" task-3] org.jboss.remoting.endpoint: Registered successful result org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication$2$1@2e963f96
2015-03-29 05:00:54,533 TRACE [Remoting "endpoint" read-1] org.jboss.remoting.endpoint: Resource closed count 00000001 of endpoint "endpoint" <4b03debc> (closed Remoting connection <4d713ca3>)
2015-03-29 05:00:54,533 TRACE [Collectd-Thread-7-of-150] org.jboss.remoting.endpoint: Finished phase 1 shutdown of endpoint "endpoint" <4b03debc>
2015-03-29 05:00:54,559 TRACE [Collectd-Thread-125-of-150] org.jboss.remoting.endpoint: Finished phase 1 shutdown of endpoint "endpoint" <268c16fa>
2015-03-29 05:00:54,559 TRACE [Remoting "endpoint" read-1] org.jboss.remoting.endpoint: Resource closed count 00000001 of endpoint "endpoint" <268c16fa> (closed Remoting connection <4d94514f>)
2015-03-29 05:00:54,562 TRACE [Remoting "endpoint" read-1] org.jboss.remoting.endpoint: Resource closed count 00000001 of endpoint "endpoint" <f8ae998> (closed Remoting connection <50aacf67>)
2015-03-29 05:00:54,562 TRACE [Collectd-Thread-77-of-150] org.jboss.remoting.endpoint: Finished phase 1 shutdown of endpoint "endpoint" <f8ae998>
2015-03-29 05:00:54,602 TRACE [Remoting "endpoint" read-1] org.jboss.remoting.endpoint: Resource closed count 00000001 of endpoint "endpoint" <5368a58f> (closed Remoting connection <3ee11848>)
2015-03-29 05:00:54,602 TRACE [Collectd-Thread-27-of-150] org.jboss.remoting.endpoint: Finished phase 1 shutdown of endpoint "endpoint" <5368a58f>
2015-03-29 09:51:32,488 ERROR [Remoting "endpoint" read-1] org.xnio.listener: A channel event listener threw an exception
java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication$1@513f87d4 rejected from org.xnio.XnioWorker$TaskPool@21ee98f8[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 1]
at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048)
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1372)
at org.xnio.XnioWorker.execute(XnioWorker.java:572)
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication.handleEvent(ClientConnectionOpenListener.java:671)
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication.handleEvent(ClientConnectionOpenListener.java:607)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at org.xnio.ssl.JsseConnectedSslStreamChannel.handleReadable(JsseConnectedSslStreamChannel.java:180)
at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:198)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (WFLY-4843) Wildfly 9 missing commons-configuration module
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4843?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-4843:
-----------------------------------
If it was removed, it was because no other module in wildfly was using it, so no reason for us to provide it.
IIRC, one of our subsystems(or its dependencies) required it long time ago but that requirement now gone.
> Wildfly 9 missing commons-configuration module
> ----------------------------------------------
>
> Key: WFLY-4843
> URL: https://issues.jboss.org/browse/WFLY-4843
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 9.0.0.CR2
> Reporter: Brett Meyer
> Assignee: Jason Greene
>
> Definitely not a big deal to provide the commons-configuration jar on our own. But, was there any reason for the module's removal in WF 9, while most other commons-* modules remain?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (WFLY-4844) When Wildfly EJB timer finishes, the transaction is not fully committed.
by xiaodong xie (JIRA)
xiaodong xie created WFLY-4844:
----------------------------------
Summary: When Wildfly EJB timer finishes, the transaction is not fully committed.
Key: WFLY-4844
URL: https://issues.jboss.org/browse/WFLY-4844
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 8.2.0.Final
Environment: Ubuntu and Mac
Reporter: xiaodong xie
Priority: Critical
When a Singleton EJB timer finishes, if the next run has already started but waiting on the write lock of Singleton EJB, the next run won't see the changes committed by the current run. So I assume when the EJB timers finishes, the transaction is not fully committed, or it's the next run that starts too early.
Here is a test case that should be able to reproduce the issue we are facing.
https://github.com/xiaodong-xie/wildfly-singleton-timer
Here is my analysis of this issue:
The CMTTxInterceptor is applied before ContainerManagedConcurrencyInterceptor.
So when waiting for the write lock of EJBReadWriteLock, we've already started the transaction, which IMHO is earlier than necessary.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (WFLY-4843) Wildfly 9 missing commons-configuration module
by Brett Meyer (JIRA)
Brett Meyer created WFLY-4843:
---------------------------------
Summary: Wildfly 9 missing commons-configuration module
Key: WFLY-4843
URL: https://issues.jboss.org/browse/WFLY-4843
Project: WildFly
Issue Type: Bug
Affects Versions: 9.0.0.CR2
Reporter: Brett Meyer
Assignee: Jason Greene
Definitely not a big deal to provide the commons-configuration jar on our own. But, was there any reason for the module's removal in WF 9, while most other commons-* modules remain?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (WFLY-4842) A resource packaged in a RAR file fails to call a native library packaged in the same RAR.
by Alex Lashchuk (JIRA)
Alex Lashchuk created WFLY-4842:
-----------------------------------
Summary: A resource packaged in a RAR file fails to call a native library packaged in the same RAR.
Key: WFLY-4842
URL: https://issues.jboss.org/browse/WFLY-4842
Project: WildFly
Issue Type: Bug
Components: Class Loading
Affects Versions: 9.0.0.CR2, 8.2.0.Final
Environment: Windows 7, 64-bit
Reporter: Alex Lashchuk
Assignee: David Lloyd
JSR322, section 20.2.0.2, specifies that native libraries, packaged at an arbitrary location in a resource adapter's RAR file, will be made available to resource adapter's managed code. In fact, section 20.2.0.1 requires that the platform-specific libraries be packaged with the resource adapter module instead of being placed on java.library.path. However, attempting to access a native library included in a RAR from resource adapter code on WildFly results in an UnsatisfiedLinkError.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (WFLY-4841) Injection of a JCA connection factory exposed from a RAR into a CDI bean fails due to class loading issues.
by Alex Lashchuk (JIRA)
Alex Lashchuk created WFLY-4841:
-----------------------------------
Summary: Injection of a JCA connection factory exposed from a RAR into a CDI bean fails due to class loading issues.
Key: WFLY-4841
URL: https://issues.jboss.org/browse/WFLY-4841
Project: WildFly
Issue Type: Bug
Components: Class Loading
Affects Versions: 9.0.0.CR2, 8.2.0.Final
Environment: Windows 7, 64-bit
Reporter: Alex Lashchuk
Assignee: David Lloyd
Attempting to inject a connection factory from a RAR into an enterprise application by interface results in a NoClassDefFoundError while looking for the interface class definition. This is likely in violation of JSR342 section EE.8.3.2.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (WFLY-4827) Network Connection leak on client abort connection
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4827?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4827:
--------------------------------------
ah, sorry, I left off:
git checkout 1.1.x
To checkout the 1.1 branch.
I am not sure about that error though, it looks like a network connection error with maven central.
> Network Connection leak on client abort connection
> --------------------------------------------------
>
> Key: WFLY-4827
> URL: https://issues.jboss.org/browse/WFLY-4827
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow), Web Sockets
> Affects Versions: 8.2.0.Final
> Environment: On Windows Server 2012, JDK 1.8.0_45, Wildfly 8.2.0.Final in standalone mode.
> Reporter: Andrea Bertolini
> Assignee: Stuart Douglas
>
> We have a classic client-server application, all written in Java. Each client is installed on a forklift which can move all around a large area. This area is under wi-fi coverage.
> Sometimes the clients can have a bad connection quality and the client-server communication is interrupted; in such a case it takes too many seconds to be restored.
> To fix this situation, we add a timeout client-side. After 5 seconds it aborts the call and tries again a second time.
> To achieve this call we use apache httpcomponents library (version 4.4). We use the abort method of httppost to interrupt this call.
> Server-side, we have a group of web-servlets which listen to the incoming calls, manage requests and send a response.
> It appears that sometimes a communication remains stuck in reading or writing from/to the stream. When the client aborts the communication, an exception is thrown on the server caused by the channel being closed.
> It happens that a large number of connections remains stuck in connection status 'established' (only server-side) even if the real connection is actually closed (client doesn't have that connection active anymore).
> When the number of established connections grows up to 200, server stops responding on port 8080, so it cannot accept more connections and it seems to freeze.
> We tried to add tcp-keep-alive=true and no-request-timeout=120000 on http-listener in undertow subsystem, but sometimes it removes idle connections after any incoming requests are received for 2 minutes, some other times it keep connections as established and doesn't close them.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (WFLY-4827) Network Connection leak on client abort connection
by Andrea Bertolini (JIRA)
[ https://issues.jboss.org/browse/WFLY-4827?page=com.atlassian.jira.plugin.... ]
Andrea Bertolini commented on WFLY-4827:
----------------------------------------
With correct url i can download the new branch...
But using mvn install i get this error.
[INFO] Scanning for projects...
Downloading: http://repository.jboss.org/nexus/content/groups/public/org/jboss/jboss-p...
Downloaded: http://repository.jboss.org/nexus/content/groups/public/org/jboss/jboss-p... (31 KB at 22.7 KB/sec)
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO]
[INFO] Undertow
[INFO] Undertow Parser Generator
[INFO] Undertow Core
[INFO] Undertow Servlet
[INFO] Undertow WebSockets JSR356 implementations
[INFO] Undertow Examples
[INFO] Undertow HTTP2 test suite
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Undertow 1.3.0.Beta3-SNAPSHOT
[INFO] ------------------------------------------------------------------------
Downloading: http://repository.jboss.org/nexus/content/groups/public/org/apache/maven/...
Downloading: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-enfor...
giu 29, 2015 5:37:11 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFORMAZIONI: I/O exception (java.net.SocketException) caught when processing request to {s}->https://repo.maven.apache.org:443: Connection reset
giu 29, 2015 5:37:11 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFORMAZIONI: Retrying request to {s}->https://repo.maven.apache.org:443
giu 29, 2015 5:37:32 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFORMAZIONI: I/O exception (java.net.SocketException) caught when processing request to {s}->https://repo.maven.apache.org:443: Connection reset
giu 29, 2015 5:37:32 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFORMAZIONI: Retrying request to {s}->https://repo.maven.apache.org:443
giu 29, 2015 5:37:53 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFORMAZIONI: I/O exception (java.net.SocketException) caught when processing request to {s}->https://repo.maven.apache.org:443: Connection reset
giu 29, 2015 5:37:53 PM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFORMAZIONI: Retrying request to {s}->https://repo.maven.apache.org:443
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] Undertow ........................................... FAILURE [01:26 min]
[INFO] Undertow Parser Generator .......................... SKIPPED
[INFO] Undertow Core ...................................... SKIPPED
[INFO] Undertow Servlet ................................... SKIPPED
[INFO] Undertow WebSockets JSR356 implementations ......... SKIPPED
[INFO] Undertow Examples .................................. SKIPPED
[INFO] Undertow HTTP2 test suite .......................... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 01:28 min
[INFO] Finished at: 2015-06-29T17:38:15+02:00
[INFO] Final Memory: 13M/150M
[INFO] ------------------------------------------------------------------------
[ERROR] Plugin org.apache.maven.plugins:maven-enforcer-plugin:1.4 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-enforcer-plugin:jar:1.4: Could not trans
fer artifact org.apache.maven.plugins:maven-enforcer-plugin:pom:1.4 from/to central (https://repo.maven.apache.org/maven2): Connection reset -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException
But did I download 1.3.0 version??
[INFO] Building Undertow 1.3.0.Beta3-SNAPSHOT
> Network Connection leak on client abort connection
> --------------------------------------------------
>
> Key: WFLY-4827
> URL: https://issues.jboss.org/browse/WFLY-4827
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow), Web Sockets
> Affects Versions: 8.2.0.Final
> Environment: On Windows Server 2012, JDK 1.8.0_45, Wildfly 8.2.0.Final in standalone mode.
> Reporter: Andrea Bertolini
> Assignee: Stuart Douglas
>
> We have a classic client-server application, all written in Java. Each client is installed on a forklift which can move all around a large area. This area is under wi-fi coverage.
> Sometimes the clients can have a bad connection quality and the client-server communication is interrupted; in such a case it takes too many seconds to be restored.
> To fix this situation, we add a timeout client-side. After 5 seconds it aborts the call and tries again a second time.
> To achieve this call we use apache httpcomponents library (version 4.4). We use the abort method of httppost to interrupt this call.
> Server-side, we have a group of web-servlets which listen to the incoming calls, manage requests and send a response.
> It appears that sometimes a communication remains stuck in reading or writing from/to the stream. When the client aborts the communication, an exception is thrown on the server caused by the channel being closed.
> It happens that a large number of connections remains stuck in connection status 'established' (only server-side) even if the real connection is actually closed (client doesn't have that connection active anymore).
> When the number of established connections grows up to 200, server stops responding on port 8080, so it cannot accept more connections and it seems to freeze.
> We tried to add tcp-keep-alive=true and no-request-timeout=120000 on http-listener in undertow subsystem, but sometimes it removes idle connections after any incoming requests are received for 2 minutes, some other times it keep connections as established and doesn't close them.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months