December 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-283) EJB timers in cluster and failover support

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-283?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-283: ------------------------------ Fix Version/s: 8.0.0.Final > EJB timers in cluster and failover support > ------------------------------------------ > > Key: WFLY-283 > URL: https://issues.jboss.org/browse/WFLY-283 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Clustering, EJB > Reporter: Radoslav Husar > Assignee: Paul Ferraro > Fix For: 8.0.0.CR1, 8.0.0.Final > > > Support for clustered EJB timer service providing failover. -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-285) Add clustered database based timers

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-285?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-285: ------------------------------ Fix Version/s: 8.0.0.Final > Add clustered database based timers > ----------------------------------- > > Key: WFLY-285 > URL: https://issues.jboss.org/browse/WFLY-285 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: EJB > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 8.0.0.CR1, 8.0.0.Final > > > Clustering should be supported for database timers. > The general ideal will be that a single database is shared by all nodes in the cluster. When a timer is created it will be inserted into the database. Periodically at a configured interval nodes will refresh their list of active timers from the database. > When a timer expires a node will attempt to grab ownership of the timer in the database by updating the row. Due to the use of either optimisitic locking or traditional DB locks only 1 node will be successful, and that node will run the task. > We will also support write only nodes, nodes that can create timer tasks, but do not attempt to run them, to allow timer tasks to be run by a subset of the nodes. > So that you don't have hundreds of existing partition name feature will allow clustered timers to be grouped into smaller partitions, so you can limit the number of nodes that are contending for a timer. -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-301) Undertow management API

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-301?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-301: ------------------------------ Fix Version/s: 8.0.0.Final > Undertow management API > ----------------------- > > Key: WFLY-301 > URL: https://issues.jboss.org/browse/WFLY-301 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management, Web (Undertow) > Reporter: Heiko Braun > Assignee: Tomaz Cerar > Fix For: 8.0.0.CR1, 8.0.0.Final > > > Expose undertow subsystem management opertions -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-305) Implement mail inflow

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-305?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-305: ------------------------------ Fix Version/s: 8.0.0.Final > Implement mail inflow > --------------------- > > Key: WFLY-305 > URL: https://issues.jboss.org/browse/WFLY-305 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: EE > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 8.0.0.CR1, 8.0.0.Final > > > in previous versions of as we had mail-ra resource adapter that added functionality of handling inflow mails. > there is implementation of this ironjacamar so the code could be reused. > Resource addapter could/should be added the same way hornetq addapter is added in messaging subsystem. > code and documentation from ironjacamer > https://svn.jboss.org/repos/jbossas/projects/jboss-jca/trunk/adapters/src... > http://docs.jboss.org/ironjacamar/userguide/1.1/en-US/html/introduction.h... -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-288) SecurityDomainJndiInjectable should allow "java:/jaas" prefixed security domain on demand

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-288?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-288: ------------------------------ Fix Version/s: 8.0.0.Final > SecurityDomainJndiInjectable should allow "java:/jaas" prefixed security domain on demand > ----------------------------------------------------------------------------------------- > > Key: WFLY-288 > URL: https://issues.jboss.org/browse/WFLY-288 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Security > Reporter: Anil Saldhana > Assignee: Stefan Guilhen > Fix For: 8.0.0.CR1, 8.0.0.Final > > > Currently, security domain strings of the form "java:/jaas/sd" are not resolving properly. IMO we should allow users to deploy applications on AS4,5,6,7 if they need to. > So have a flag inside the SecurityDomainJndiInjectable class that is turned off by default. If you turn it on, then "java:/jaas" is unprefixed if present. -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-307) Add ability to migrate timers between data stores

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-307?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-307: ------------------------------ Fix Version/s: 8.0.0.Final > Add ability to migrate timers between data stores > ------------------------------------------------- > > Key: WFLY-307 > URL: https://issues.jboss.org/browse/WFLY-307 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: EJB > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 8.0.0.CR1, 8.0.0.Final > > > It should be possible to move timers between data stores, so that timers can be migrated from the legacy file store. -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-316) Javadoc - exclude _private.* packages

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-316?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-316: ------------------------------ Fix Version/s: 8.0.0.Final > Javadoc - exclude _private.* packages > ------------------------------------- > > Key: WFLY-316 > URL: https://issues.jboss.org/browse/WFLY-316 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Documentation > Reporter: Ondrej Zizka > Assignee: Ondrej Zizka > Priority: Minor > Fix For: 8.0.0.CR1, 8.0.0.Final > > -- 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

12 years, 7 months

1
0
0 / 0

[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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-324) xinclude support in the management model

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-324?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-324: ------------------------------ Fix Version/s: 8.0.0.Final > xinclude support in the management model > ---------------------------------------- > > Key: WFLY-324 > URL: https://issues.jboss.org/browse/WFLY-324 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Jason Greene > Fix For: 8.0.0.CR1, 8.0.0.Final > > > Ability to use xinclude in the domain/xml/host.xml/standalone.xml documents. Not necessarily anywhere, but where the model supports storing the information. Upon changes to the model, persistence of the relevant elements would be to the specified file. -- 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

12 years, 7 months

1
0
0 / 0

[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

12 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2013