[JBoss JIRA] (WFLY-6892) Access logging for EJBs
by Harald Pehl (Jira)
[ https://issues.jboss.org/browse/WFLY-6892?page=com.atlassian.jira.plugin.... ]
Harald Pehl updated WFLY-6892:
------------------------------
Labels: affects-model affects_elytron (was: affects_elytron)
> Access logging for EJBs
> -----------------------
>
> Key: WFLY-6892
> URL: https://issues.jboss.org/browse/WFLY-6892
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Affects Versions: 10.0.0.Final
> Reporter: Brad Maxwell
> Assignee: Cheng Fang
> Priority: Major
> Labels: affects-model, affects_elytron
>
> Access logging for EJB requests similar to Web access logging would be very useful.
> Possibly something like:
> {code}
> [date-time] [host/IP of caller] [EJB Name] [EJB Method] [invocation id] Request Received ...
> [date-time] [host/IP of caller] [EJB Name] [EJB Method] invocation id] Starting Invocation ...
> [date-time] [host/IP of caller] [EJB Name] [EJB Method] invocation id] Finished Invocation ...
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-6944) Encode session affinity using multiple routes, if supported by the load balancer
by Harald Pehl (Jira)
[ https://issues.jboss.org/browse/WFLY-6944?page=com.atlassian.jira.plugin.... ]
Harald Pehl updated WFLY-6944:
------------------------------
Labels: affects-model (was: )
> Encode session affinity using multiple routes, if supported by the load balancer
> --------------------------------------------------------------------------------
>
> Key: WFLY-6944
> URL: https://issues.jboss.org/browse/WFLY-6944
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
> Labels: affects-model
>
> Currently, session affinity is specified as a single route, usually the primary owner of a session. However, if this node is not active (from the load balancer's perspective), then the load balancer will select another node of its choosing. This is less than ideal, since some nodes are more optimal than others. Better is to expression session affinity as an ordered list of nodes. The load balancer can then choose the 1st node in the list that is active, and cascade on failures accordingly. From the server's perspective, the affinity list should have the following order:
> 1. The primary owner
> 2. Any backup owners
> 3. The local node (if the local node is not an owner)
> There are a couple of ways a load balancer can indicate that it supports multiple routes.
> 1. Static configuration, e.g. routing="NONE|OWNER|LOCAL|RANKED"
> 2. Adding an HTTP header to a proxied request, which can be detected by the server handling the request
> #1 has the advantage of simplicity - but requires that users manually apply this configuration to gain optimal performance. This would also let us allow users (for even the single node affinity case) to toggle between local affinity or primary owner affinity, or even no routing.
> #2 has the advantage of applying this optimization automatically, but incurs the cost of an additional header to every request
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-11943) Statistics of REST endpoints
by Harald Pehl (Jira)
[ https://issues.jboss.org/browse/WFLY-11943?page=com.atlassian.jira.plugin... ]
Harald Pehl updated WFLY-11943:
-------------------------------
Labels: affects-model (was: )
> Statistics of REST endpoints
> ----------------------------
>
> Key: WFLY-11943
> URL: https://issues.jboss.org/browse/WFLY-11943
> Project: WildFly
> Issue Type: Feature Request
> Components: REST
> Affects Versions: 17.0.0.Final
> Reporter: r searls
> Assignee: r searls
> Priority: Major
> Labels: affects-model
>
> Provide statistics on REST endpoints in the jaxrs subsystem.
> CLI support "read-resource" operation for jax-rs subsystem in deployment:
> /deployment=jaxrs-eap.war/subsystem=jaxrs:read-resource
> Statistics should be added to results of this operation in this RFE.
> There needs to be option to enable or disable collecting of these statistics, because collecting of statistics does probably some performance drop.
> The change of statistic settings should not require server reload or restart.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (JGRP-2350) TCP: connection close can block when send() block on full TCP send-window
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2350?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2350:
---------------------------
Fix Version/s: 4.1.1
> TCP: connection close can block when send() block on full TCP send-window
> -------------------------------------------------------------------------
>
> Key: JGRP-2350
> URL: https://issues.jboss.org/browse/JGRP-2350
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.1
>
>
> When a peer is non-responsive (without closing its socket), a TcpConnection.send() can block on a write (state is RUNNABLE!).
> The problem is that the TcpConnection cannout be closed either, as TcpConnection.close() tries to acquire the same lock already held by TcpConnection.send().
> See the stack trace below for a sample scenario.
> The use case is this one:
> * Say we have nodes A (coord), B and C
> * There's heavy (clustering) traffic to all 3 nodes, from the 2 clients
> * B is isolated by executing 'ifdown bond0'
> * At this point, the messages going to B will back up at (say) A because A doesn't get any TCP acks from B
> * At some point, depending on the traffic and the size of the sent messages, A will acquire a lock on the send connection to B, to write data, but the write will block as the TCP send-window to B is full (note that the sender thread will still be in state RUNNABLE!)
> * After 40s, A suspects B and emits a new view {A,C}
> * This causes A's connection to B to be closed and subsequently removed. However, this _won't_ happen, as the connection close will need to acquire the connection lock, which is held by the TCP write
> {noformat}
> "main" #1 prio=5 os_prio=31 tid=0x00007fbbd3802000 nid=0x2303 runnable [0x0000700009793000]
> java.lang.Thread.State: RUNNABLE
> at java.net.SocketOutputStream.socketWrite0(Native Method)
> at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:111)
> at java.net.SocketOutputStream.write(SocketOutputStream.java:155)
> at java.io.BufferedOutputStream.write(BufferedOutputStream.java:122)
> - locked <0x000000079e790a50> (a java.io.BufferedOutputStream)
> at java.io.DataOutputStream.write(DataOutputStream.java:107)
> - locked <0x000000079e790838> (a java.io.DataOutputStream)
> at org.jgroups.blocks.cs.TcpConnection.doSend(TcpConnection.java:161)
> at org.jgroups.blocks.cs.TcpConnection.send(TcpConnection.java:131)
> at org.jgroups.blocks.cs.TcpClient.send(TcpClient.java:103)
> at org.jgroups.tests.bla6.main(bla6.java:35)
> "Thread-2" #15 prio=5 os_prio=31 tid=0x00007fbbd2150800 nid=0x6503 waiting on condition [0x000070000bcf6000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000000079e7871a8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
> at org.jgroups.blocks.cs.TcpConnection.close(TcpConnection.java:358)
> at org.jgroups.util.Util.close(Util.java:422)
> at org.jgroups.blocks.cs.TcpClient.stop(TcpClient.java:85)
> at org.jgroups.blocks.cs.BaseServer.close(BaseServer.java:147)
> at org.jgroups.util.Util.close(Util.java:422)
> at org.jgroups.tests.bla6.lambda$main$0(bla6.java:27)
> at org.jgroups.tests.bla6$$Lambda$1/1384010761.run(Unknown Source)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (JGRP-2350) TCP: connection close can block when send() block on full TCP send-window
by Bela Ban (Jira)
Bela Ban created JGRP-2350:
------------------------------
Summary: TCP: connection close can block when send() block on full TCP send-window
Key: JGRP-2350
URL: https://issues.jboss.org/browse/JGRP-2350
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
When a peer is non-responsive (without closing its socket), a TcpConnection.send() can block on a write (state is RUNNABLE!).
The problem is that the TcpConnection cannout be closed either, as TcpConnection.close() tries to acquire the same lock already held by TcpConnection.send().
See the stack trace below for a sample scenario.
The use case is this one:
* Say we have nodes A (coord), B and C
* There's heavy (clustering) traffic to all 3 nodes, from the 2 clients
* B is isolated by executing 'ifdown bond0'
* At this point, the messages going to B will back up at (say) A because A doesn't get any TCP acks from B
* At some point, depending on the traffic and the size of the sent messages, A will acquire a lock on the send connection to B, to write data, but the write will block as the TCP send-window to B is full (note that the sender thread will still be in state RUNNABLE!)
* After 40s, A suspects B and emits a new view {A,C}
* This causes A's connection to B to be closed and subsequently removed. However, this _won't_ happen, as the connection close will need to acquire the connection lock, which is held by the TCP write
{noformat}
"main" #1 prio=5 os_prio=31 tid=0x00007fbbd3802000 nid=0x2303 runnable [0x0000700009793000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:111)
at java.net.SocketOutputStream.write(SocketOutputStream.java:155)
at java.io.BufferedOutputStream.write(BufferedOutputStream.java:122)
- locked <0x000000079e790a50> (a java.io.BufferedOutputStream)
at java.io.DataOutputStream.write(DataOutputStream.java:107)
- locked <0x000000079e790838> (a java.io.DataOutputStream)
at org.jgroups.blocks.cs.TcpConnection.doSend(TcpConnection.java:161)
at org.jgroups.blocks.cs.TcpConnection.send(TcpConnection.java:131)
at org.jgroups.blocks.cs.TcpClient.send(TcpClient.java:103)
at org.jgroups.tests.bla6.main(bla6.java:35)
"Thread-2" #15 prio=5 os_prio=31 tid=0x00007fbbd2150800 nid=0x6503 waiting on condition [0x000070000bcf6000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x000000079e7871a8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
at org.jgroups.blocks.cs.TcpConnection.close(TcpConnection.java:358)
at org.jgroups.util.Util.close(Util.java:422)
at org.jgroups.blocks.cs.TcpClient.stop(TcpClient.java:85)
at org.jgroups.blocks.cs.BaseServer.close(BaseServer.java:147)
at org.jgroups.util.Util.close(Util.java:422)
at org.jgroups.tests.bla6.lambda$main$0(bla6.java:27)
at org.jgroups.tests.bla6$$Lambda$1/1384010761.run(Unknown Source)
at java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month