[JBoss JIRA] (WFLY-315) Avoid running out of threads when connecting to the DC from a slave to pull down missing data
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-315?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-315:
------------------------------
Fix Version/s: 8.0.0.Final
> 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
> Fix For: 8.0.0.CR1, 8.0.0.Final
>
>
> 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
10 years, 6 months
[JBoss JIRA] (WFLY-320) Allow jconsole to be launched as a modular application
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-320?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-320:
------------------------------
Fix Version/s: 8.0.0.Final
> Allow jconsole to be launched as a modular application
> ------------------------------------------------------
>
> Key: WFLY-320
> URL: https://issues.jboss.org/browse/WFLY-320
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JMX, Scripts
> Reporter: Brian Stansberry
> Fix For: 8.0.0.CR1, 8.0.0.Final
>
>
> Make the jconsole scripts launch jconsole as as a modular application. Get rid of the classpath building that resulted in AS7-6498.
> Some (mildly edited) discussion:
> bstansberry: BTW, I filed a JIRA to make the vault tool a proper modular app in AS next. I'm not sure if that's doable for jconsole
> [10:37am] darranl: bstansberry: Yes vault should be modular - I don't believe jconsole is as easily possible unless we add a module for the jconsole classes
> [10:38am] darranl: bstansberry: the problem with jconsole was that we actually needed to call jconsole which I think was a binary so we were just created an extended classpath for that binary to use
> [10:38am] bstansberry: darranl: ok, will do. I didn't file a JIRA for modular jconsole because I figured there would be problems
> [10:39am] darranl: bstansberry: having said that it may be possible now to just switch to use the client jar - that did not exist at the time the jconsole script was first written
> [10:40am] darranl: but at this point may be safer to just update the root of the modules folder and switch to client later
> [10:40am] bstansberry: darranl: this will become more of an issue once we have patching
> [10:40am] bstansberry: since this script won't pick up any patches we may have issued for the listed modules
> [10:40am] bstansberry: and no way are we going to add that to the script
> [10:43am] dmlloyd: I've booted jconsole from within modules before
> [10:43am] dmlloyd: it's possible
> [10:43am] darranl: If it is possbile then maybe we can just make it modular
> [10:44am] dmlloyd: java -jar ~/.m2/repository/org/jboss/modules/jboss-modules/1.1.4.GA/jboss-modules-1.1.4.GA.jar -jar ~/local/jdk/home/lib/jconsole.jar
> [10:44am] dmlloyd: easy as bananas
> [10:45am] dmlloyd: if you use -cp you can also add dependencies via -dep
> [10:45am] dmlloyd: or we could create a jconsole module from openjdk even
--
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
10 years, 6 months
[JBoss JIRA] (WFLY-343) lower messaging's min-large-message-size value in standalone-full.xml
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-343?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-343:
------------------------------
Fix Version/s: 8.0.0.Final
> lower messaging's min-large-message-size value in standalone-full.xml
> ---------------------------------------------------------------------
>
> Key: WFLY-343
> URL: https://issues.jboss.org/browse/WFLY-343
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 8.0.0.CR1, 8.0.0.Final
>
>
> AS7's messaging subsystem defines 2 attributes:
> journal-file-size => 10MiB
> min-large-message-size => 100KiB
> However, for startup performance issue, the standalone-full.xml sets the journal-file-size at 1OOKiB. This leads to issues since it's the same value than the min-large-message-size.
> If we want to keep a low journal-file-size value in standalone-full.xml, the min-large-message-size must also bet set appropriately (eg 75KiB?)
> For production use, however, we should suggest to the users to remove the journal-file-size and min-large-message-size from standalone-full.xml to use the default values (resp. 10MiB & 100KiB)
--
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
10 years, 6 months