November 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-457) Optimization: make threads return immediately if NAKACK has another active thread for the same sender

by Bela Ban (JIRA)

Optimization: make threads return immediately if NAKACK has another active thread for the same sender ----------------------------------------------------------------------------------------------------- Key: JGRP-457 URL: http://jira.jboss.com/jira/browse/JGRP-457 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Bela Ban Priority: Minor Fix For: 2.5 In NAKACK, when a thread places a message for sender S into the NakReceiverWindow NRW, it subsequently acquires a lock on NRW (lock by sender) and removes as many messages as possible and passes them up. If many threads do this at the same time, all threads but one are blocked, and - when finally unblocked - usually return. This causes context switches and possibly cache flushing, so a better way would be to have the threads check whether another thread is already removing messages using a CAS operation *before* acquiring the lock. The effect should be that no threads will wait on the lock unnecessarily, and thus fewer context switches, and more threads available to the pool. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 week, 4 days

2
3
0 / 0

[JBoss JIRA] (WFLY-10796) Warning about JSF version 'NONE' is shown in logs

by Jan Kašík (JIRA)

[ https://issues.jboss.org/browse/WFLY-10796?page=com.atlassian.jira.plugin... ] Jan Kašík updated WFLY-10796: ----------------------------- Description: Following warning is shown in log upon server start: {code} 2018-08-02 16:13:28,487 WARN [org.jboss.as.jsf] (MSC service thread 1-3) WFLYJSF0005: Unknown JSF version 'NONE'. Default version 'main' will be used instead. {code} Seems like, that 'NONE' constant from WildFly code is somehow used instead of default 'main' value. Version 'NONE' is not specified anywhere, so this warning should not be present. From my point of view, it seems like I am trying set slot 'NONE' to be the default. But nothing like that is happening. was: Following warning is shown in log upon server start: {code} 2018-08-02 16:13:28,487 WARN [org.jboss.as.jsf] (MSC service thread 1-3) WFLYJSF0005: Unknown JSF version 'NONE'. Default version 'main' will be used instead. {code} Seems like, that 'NONE' constant from WildFly code is somehow used instead of default 'main' value. Version 'NONE' is not specified anywhere, so this warning should not be present. > Warning about JSF version 'NONE' is shown in logs > -------------------------------------------------- > > Key: WFLY-10796 > URL: https://issues.jboss.org/browse/WFLY-10796 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 14.0.0.Beta2 > Reporter: Jan Kašík > Assignee: Dmitrii Tikhomirov > > Following warning is shown in log upon server start: > {code} > 2018-08-02 16:13:28,487 WARN [org.jboss.as.jsf] (MSC service thread 1-3) WFLYJSF0005: Unknown JSF version 'NONE'. Default version 'main' will be used instead. > {code} > Seems like, that 'NONE' constant from WildFly code is somehow used instead of default 'main' value. Version 'NONE' is not specified anywhere, so this warning should not be present. From my point of view, it seems like I am trying set slot 'NONE' to be the default. But nothing like that is happening. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

1 month

2
1
0 / 0

[JBoss JIRA] (ELY-776) Eliminate reference to "slot" from module configurations

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-776?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse reassigned ELY-776: ------------------------------------ Assignee: Darran Lofthouse > Eliminate reference to "slot" from module configurations > -------------------------------------------------------- > > Key: ELY-776 > URL: https://issues.jboss.org/browse/ELY-776 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Reporter: David Lloyd > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta15 > > > The final version of our client XSD should accept a name for modules but no slot. Instead, either the new name-only APIs should be used or a ModuleIdentifier created via that class's "fromString" method. Module slots are deprecated. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

1 month

2
1
0 / 0

[JBoss JIRA] (JBRULES-3445) DSL expander expands lines in /* */comment block

by Mario Fusco (JIRA)

Mario Fusco created JBRULES-3445: ------------------------------------ Summary: DSL expander expands lines in /* */comment block Key: JBRULES-3445 URL: https://issues.jboss.org/browse/JBRULES-3445 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Mario Fusco Assignee: Mario Fusco When you comment some code in dslr file, the expander still tries to expand it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

6 months

3
10
0 / 0

[JBoss JIRA] (WFLY-7186) Security 1.0 Support (JSR 375) With WildFly Elytron

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-7186?page=com.atlassian.jira.plugin.... ] James Perkins updated WFLY-7186: -------------------------------- Fix Version/s: 16.0.0.Beta1 (was: 15.0.0.Final) > Security 1.0 Support (JSR 375) With WildFly Elytron > --------------------------------------------------- > > Key: WFLY-7186 > URL: https://issues.jboss.org/browse/WFLY-7186 > Project: WildFly > Issue Type: Sub-task > Components: Security > Reporter: David Lloyd > Assignee: Darran Lofthouse > Priority: Major > Fix For: 16.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11309) Use registered priorities for MP Config DUP

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-11309?page=com.atlassian.jira.plugin... ] James Perkins updated WFLY-11309: --------------------------------- Fix Version/s: 16.0.0.Beta1 (was: 15.0.0.Final) > Use registered priorities for MP Config DUP > ------------------------------------------- > > Key: WFLY-11309 > URL: https://issues.jboss.org/browse/WFLY-11309 > Project: WildFly > Issue Type: Bug > Components: MP Config > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Major > Fix For: 16.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11214) Periodic recovery does not recover XAResource after jvm crash when agroal subsystem is used

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-11214?page=com.atlassian.jira.plugin... ] James Perkins updated WFLY-11214: --------------------------------- Fix Version/s: 16.0.0.Beta1 (was: 15.0.0.Final) > Periodic recovery does not recover XAResource after jvm crash when agroal subsystem is used > ------------------------------------------------------------------------------------------- > > Key: WFLY-11214 > URL: https://issues.jboss.org/browse/WFLY-11214 > Project: WildFly > Issue Type: Bug > Components: Agroal, Transactions > Reporter: Ivan Straka > Assignee: Luis Barreiro > Priority: Blocker > Fix For: 16.0.0.Beta1 > > Attachments: JPACrashRecoveryTestCase_commitHaltSecond_jta_server.log, JPACrashRecoveryTestCase_commitHaltSecond_jts_server.log > > > Scenario: > Halts server at commit phase ... > # enlist TestXA resource > # enlist XA resource > # prepare TestXA resource > # prepare XA resource > # commit Test XA resource > # JVM crash > # recovery started > # commit XA resource > Periodic recovery does not recover xa resource. It looks like agroal subsystem does not register xa resource to xa recovery module. > Test outcome: > {code:java} > Running org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase > Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 109.002 sec <<< FAILURE! - in org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase > commitHaltSecond(org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase) Time elapsed: 102.976 sec <<< FAILURE! > java.lang.AssertionError: Incorrect data in database after crash recovery. expected:<2> but was:<1> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:645) > at org.jboss.as.test.jbossts.crashrec.test.JPABaseCrashRecoveryTestCase.checkAfterTestExecution(JPABaseCrashRecoveryTestCase.java:150) > at org.jboss.as.test.jbossts.crashrec.test.TestBaseCrashRecovery.commitHaltTest(TestBaseCrashRecovery.java:485) > at org.jboss.as.test.jbossts.crashrec.test.TestBaseCrashRecovery.commitHaltSecond(TestBaseCrashRecovery.java:418) > at org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase.commitHaltSecond(JPACrashRecoveryTestCase.java:76) > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11143) Message sent to JMSReplyTo from old client does not find correct binding

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-11143?page=com.atlassian.jira.plugin... ] James Perkins updated WFLY-11143: --------------------------------- Fix Version/s: 16.0.0.Beta1 (was: 15.0.0.Final) > Message sent to JMSReplyTo from old client does not find correct binding > ------------------------------------------------------------------------ > > Key: WFLY-11143 > URL: https://issues.jboss.org/browse/WFLY-11143 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 14.0.0.Final > Reporter: Miroslav Novak > Assignee: Martyn Taylor > Priority: Blocker > Fix For: 16.0.0.Beta1 > > > There is regression in backward compatibility of messaging client. JMSReplyTo destination set by older client contains incorrect address which causes that reply message does not have correct binding and such message is lost. > Impact: Applications will stop work after upgrade to WF14/EAP 7.2.0.CD14. > Test Scenario: > * Start EAP 7.2.0.CD14/WF14 server (Artemis 2.x) with deployed InQueue and OutQueue > * Send message to InQueue from older EAP 7.2.0.CD13/WF13/Artemis 1.5.5 client to InQueue. Message has JMSReplyTo header set to OutQueue. Client got "OutQueue" queue from JNDI lookup from EAP7.2.0.CD14/WF14 > * Deploy MDB to server > ** MDB consumes message from InQueue and sends new message to destination defined in JMSReplyTo header (so to OutQueue) > * Receive message from OutQueue > Result: > No message is received from OutQueue. There is debug message in server log: > {code} > 11:36:09,565 DEBUG [org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl] (Thread-25 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@22848193)) Message CoreMessage[m > essageID=214,durable=true,userID=c0de8bd0-cba6-11e8-840f-f496342f6705,priority=4, timestamp=Tue Oct 09 11:36:09 CEST 2018,expiration=0, durable=true, address=jms.queue.OutQueue,size=580,properties=TypedPropertie > s[inMessageId=ID:c0383a39-cba6-11e8-95ad-f496342f6705,__AMQ_CID=c0d9349a-cba6-11e8-840f-f496342f6705,_AMQ_DUPL_ID=90d1e80e-116d-4eef-9513-84c6085549db,_AMQ_ROUTING_TYPE=0]]@1680840457 is not going anywhere as it > didn't have a binding on address:jms.queue.OutQueue > {code} > which indicates that jms.queue.OutQueue address does not have a binding. > The same happesn if older EAP/WF server (with Artemis 1.5.5x) is used and new EAP 7.2.0.CD14/WF14(Artemis 2.x) client is used. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11101) Add CredentialStore documentation

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-11101?page=com.atlassian.jira.plugin... ] James Perkins updated WFLY-11101: --------------------------------- Fix Version/s: 16.0.0.Beta1 (was: 15.0.0.Final) > Add CredentialStore documentation > --------------------------------- > > Key: WFLY-11101 > URL: https://issues.jboss.org/browse/WFLY-11101 > Project: WildFly > Issue Type: Task > Components: Documentation, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 16.0.0.Beta1 > > > The CredentialStore is a significant component within WildFly Elytron, however it is not really covered in the documentation. > We have a couple of different approaches to creating the store, we then have referencing the store. Finally we have custom implementations. > New features are also being developed so really we need a source of documentation to add descriptions of the new features to. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11073) Support hex encoding in jdbc-realm for elytron

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-11073?page=com.atlassian.jira.plugin... ] James Perkins updated WFLY-11073: --------------------------------- Fix Version/s: 16.0.0.Beta1 (was: 15.0.0.Final) > Support hex encoding in jdbc-realm for elytron > ---------------------------------------------- > > Key: WFLY-11073 > URL: https://issues.jboss.org/browse/WFLY-11073 > Project: WildFly > Issue Type: Feature Request > Components: Documentation, Security > Reporter: Jan Kalina > Priority: Major > Labels: elytron > Fix For: 16.0.0.Beta1 > > > Old database login-module can be configured passing the attribute {{hashEncoding}}, for example: > {code:xml} > <login-module code="Database" flag="required"> > <module-option name="dsJndiName" value="java:jboss/datasources/ExampleDS"/> > <module-option name="principalsQuery" value="SELECT password FROM User WHERE username = ?"/> > <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM User WHERE username = ?"/> > <module-option name="hashAlgorithm" value="SHA-1"/> > <module-option name="hashEncoding" value="hex"/> > <module-option name="hashCharset" value="UTF-8"/> > </login-module> > {code} > Currently jdbc-realm in elytron only uses base64 encoding if hash is stored in a text column. This way the migration is more complicated cos the password hash is not valid changing from old security system to elytron. > Think also about the charset attribute. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2018