[
https://issues.jboss.org/browse/WFLY-315?page=com.atlassian.jira.plugin.s...
]
Brian Stansberry commented on WFLY-315:
---------------------------------------
The IO I'm talking about is writes. The reads are all done by remoting threads, so
that's fine. But in many places the thread executing an op itself writes, e.g. to
proxy a request, to send a prepared, failed or completed response, or to send a
commit/rollback instruction. The problem with this is if an administrative action to
cancel the op occurs, the thread is interrupted, and when that thread later interacts with
the channel to write, the channel gets closed. Testing administratively cancelling ops
from various processes I was regularly seeing the connection from a slave to the master or
a server to its HC getting closed.
Avoid running out of threads when connecting to the DC from a slave
to pull down missing data
---------------------------------------------------------------------------------------------
Key: WFLY-315
URL:
https://issues.jboss.org/browse/WFLY-315
Project: WildFly
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: Domain Management
Reporter: Kabir Khan
Assignee: Emanuel Muckenhuber
Priority: Blocker
Fix For: 9.0.0.CR1
For WFLY-259 when a slave connects to the DC to pull down missing data, it does this by
either getting a lock for the DC, or by joining the permit of the existing DC lock if the
request to update a slave's server-config was executed as part of a composite
obtaining a lock on the DC.
The way it works at present there is a thread per slave which is blocked until the
transaction completes. The DC threads are a finite resource, so a large number of slaves
trying to pull down dats will cause deadlock
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira