November 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-217) Strict location check of persistence.xml deployments

by Caio Bessa (JIRA)

[ https://issues.jboss.org/browse/WFLY-217?page=com.atlassian.jira.plugin.s... ] Caio Bessa edited comment on WFLY-217 at 11/14/17 5:12 PM: ----------------------------------------------------------- I will start to fix that problem. was (Author: bessa): I will start to fix that problem. > Strict location check of persistence.xml deployments > ---------------------------------------------------- > > Key: WFLY-217 > URL: https://issues.jboss.org/browse/WFLY-217 > Project: WildFly > Issue Type: Enhancement > Components: JPA / Hibernate > Reporter: Bartosz Baranowski > Priority: Minor > Fix For: Awaiting Volunteers > > > As of: https://github.com/jbossas/jboss-as/commit/38815193011fba624170a7d938118e... it is possible to deploy persistence.xml from invalid location: > As per JPA spec(https://docs.jboss.org/author/display/AS71/JPA+Reference+Guide), valid locations are: > - an EJB-JAR file > - the WEB-INF/classes directory of a WAR file > - a jar file in the WEB-INF/lib directory of a WAR file > - a jar file in the EAR library directory > - an application client jar file -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-1446) Add utility methods for converting an unordered array of certificates into an ordered X.509 certificate chain and for creating an X.509 certificate chain from a map of certificates

by Farah Juma (JIRA)

Farah Juma created ELY-1446: ------------------------------- Summary: Add utility methods for converting an unordered array of certificates into an ordered X.509 certificate chain and for creating an X.509 certificate chain from a map of certificates Key: ELY-1446 URL: https://issues.jboss.org/browse/ELY-1446 Project: WildFly Elytron Issue Type: Feature Request Components: X.500 Reporter: Farah Juma Assignee: Farah Juma These utility methods will be useful for importing the response from a certificate signing request (the response will either be a PKCS #7 certificate chain, which is unordered, or a single certificate which can be used to build up a certificate chain). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9524) Messaging - default max client threads

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-9524?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-9524: ----------------------------------- With VMs/taskset/cgroups/etc. it is possible (and common) to have one (logical) CPU. > Messaging - default max client threads > -------------------------------------- > > Key: WFLY-9524 > URL: https://issues.jboss.org/browse/WFLY-9524 > Project: WildFly > Issue Type: Enhancement > Components: JMS > Affects Versions: 11.0.0.Final > Reporter: Martin Styk > Assignee: Jeff Mesnil > > By default, size of client thread pool is configured as 8 * number of CPU cores. > On 1 CPU machine, with default configuration and MDB deployed on server, resource starvation is possible > On one CPU there are by default > * 8 ActiveMQ client threads (8 * CPU count) > * 4 MDB instances (mdb-strict-max-pool = 4 * CPU count) > * 15 JCA RA sessions consuming messages from queue (default value of maxSession) > Consuming of messages by MDB gets stuck because all 8 client threads are awaiting large message completion and there is no other thread to handle other tasks. > {code:title=Client thread waiting for large message completion} > "Thread-7 (ActiveMQ-client-global-threads)" #475 daemon prio=5 os_prio=0 > tid=0x000000000590f000 nid=0x7c7a in Object.wait() [0x00007fda43413000] > java.lang.Thread.State: TIMED_WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > at > org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl.waitCompletion(LargeMessageControllerImpl.java:302) > - locked <0x00000000b0083e88> (a > org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl) > at > org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl.saveBuffer(LargeMessageControllerImpl.java:276) > - locked <0x00000000b0083e88> (a > org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl) > at > org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl.checkBuffer(ClientLargeMessageImpl.java:159) > at > org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl.checkCompletion(ClientLargeMessageImpl.java:84) > at > org.apache.activemq.artemis.jms.client.ActiveMQMessage.doBeforeReceive(ActiveMQMessage.java:786) > at > org.apache.activemq.artemis.jms.client.ActiveMQTextMessage.doBeforeReceive(ActiveMQTextMessage.java:110) > at > org.apache.activemq.artemis.ra.inflow.ActiveMQMessageHandler.onMessage(ActiveMQMessageHandler.java:295) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1001) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:49) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1124) > at > org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:748) > {code} > This can be fixed by adjusting default values for these parameters. > In this case, we need more client threads than JCA RA sessions (maxSession). > To avoid resource starvation, number of client threads must be greater than sum of {{maxSession}} for each MDB deployed on server. > We should check number of client threads required by deployments (MDBs), and at least print warning message that size of client thread pool may be insufficient. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9529) Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/WFLY-9529?page=com.atlassian.jira.plugin.... ] Eduardo Martins commented on WFLY-9529: --------------------------------------- [~jmesnil] JNDI should be available, it may be that some thread context needs to be added, or the injected context needs to be aware of it when doing the lookup, please reassign to me if you want me to look at it. > Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry > --------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-9529 > URL: https://issues.jboss.org/browse/WFLY-9529 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.1.0.Final, 11.0.0.Final > Environment: Running on Windows 10, Java 64-bit 1.8.0_131 > Reporter: Scott Van Wart > Assignee: Jeff Mesnil > Labels: ActiveMQ, jms, transaction > Attachments: injected-jms.zip, wildfly-11-injected-jms.txt > > > If I try to use an @Injected JMSContext while executing within a background task (ManagedExecutorService) or thread (ManagedThreadFactory), I get the attached stacktrace. I've experienced this a number of times with Wildfly 10.1.0, including messages sent in Infinispan's expiry task thread. > My original workaround was to submit an additional task on a separate thread to send the message, then wait for it to complete. That seemed unreliable (sometimes it would still produce NameNotFoundException). I've resorted to creating my own JMSContext by using @Resource( lookup="java:/ConnectionFactory" ) and sending messages that way. Both workarounds prevent the message sending logic from participating in any ongoing transactions. > I'm also attaching a sample EAR project. It can be built with Maven. It creates a background task that waits 3 seconds and then tries to send a JMS message in a new transaction using an injected JMS context. I use the standalone-full.xml profile to run it. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-252) Take into account username after failed authentication for available mechs

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-252?page=com.atlassian.jira.plugin.sy... ] Jan Kalina commented on ELY-252: -------------------------------- This could be in theory implemented in ServerAuthenticationContext, as default value in NameCallback - but I dont think there are some SASL mechanims for which this would be useful - all mechs I remember have to obtain username from client by protocol and protocol does not allow server to provide default to the client... > Take into account username after failed authentication for available mechs > -------------------------------------------------------------------------- > > Key: ELY-252 > URL: https://issues.jboss.org/browse/ELY-252 > Project: WildFly Elytron > Issue Type: Task > Components: SASL > Reporter: Darran Lofthouse > Fix For: 1.2.0.Beta11 > > > This is something we would need to be cautious about as it does risk revealing information to an attacker but after a files attempt we may have more information and be able to offer mechanisms based on this. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9553) PooledConnectionFactoryAdd adds a resource with no registration

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-9553?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-9553: ---------------------------------------- [~jmesnil] I would have done that except the attribute supports expressions. You can actually use AD.resolveModelAttribute(...) in Stage.MODEL and it would work fine except for vault expressions during boot. Vault expressions are not resolvable until the vault is installed in Stage.RUNTIME. > PooledConnectionFactoryAdd adds a resource with no registration > --------------------------------------------------------------- > > Key: WFLY-9553 > URL: https://issues.jboss.org/browse/WFLY-9553 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 11.0.0.Final > Reporter: Brian Stansberry > Assignee: Jeff Mesnil > Priority: Minor > > When working on WFCORE-2930 I was investigating discrepancies in mbean counts generated via the method in that fix vs current code. I discovered one in WildFly's messaging-activemq that is a result of a statistics resource being added to the resource tree even if attribute that triggers registration of the related ManagementResourceRegistration isn't set. So we have an undescribed resource. > This likely has no other impact than a slightly inaccurate result from MBeanServerConnection.getMBeanCount() but we don't want this kind of thing anyway. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9524) Messaging - default max client threads

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-9524?page=com.atlassian.jira.plugin.... ] Jeff Mesnil commented on WFLY-9524: ----------------------------------- Is that a practical issue? On my laptop, I have 8 CPU cores, this means: - 64 client threads (8 * 8) - 32 MDBs (4 * 8) - 15 JCA sessions Do we have actual cases with only 1 CPU core? > Messaging - default max client threads > -------------------------------------- > > Key: WFLY-9524 > URL: https://issues.jboss.org/browse/WFLY-9524 > Project: WildFly > Issue Type: Enhancement > Components: JMS > Affects Versions: 11.0.0.Final > Reporter: Martin Styk > Assignee: Jeff Mesnil > > By default, size of client thread pool is configured as 8 * number of CPU cores. > On 1 CPU machine, with default configuration and MDB deployed on server, resource starvation is possible > On one CPU there are by default > * 8 ActiveMQ client threads (8 * CPU count) > * 4 MDB instances (mdb-strict-max-pool = 4 * CPU count) > * 15 JCA RA sessions consuming messages from queue (default value of maxSession) > Consuming of messages by MDB gets stuck because all 8 client threads are awaiting large message completion and there is no other thread to handle other tasks. > {code:title=Client thread waiting for large message completion} > "Thread-7 (ActiveMQ-client-global-threads)" #475 daemon prio=5 os_prio=0 > tid=0x000000000590f000 nid=0x7c7a in Object.wait() [0x00007fda43413000] > java.lang.Thread.State: TIMED_WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > at > org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl.waitCompletion(LargeMessageControllerImpl.java:302) > - locked <0x00000000b0083e88> (a > org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl) > at > org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl.saveBuffer(LargeMessageControllerImpl.java:276) > - locked <0x00000000b0083e88> (a > org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl) > at > org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl.checkBuffer(ClientLargeMessageImpl.java:159) > at > org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl.checkCompletion(ClientLargeMessageImpl.java:84) > at > org.apache.activemq.artemis.jms.client.ActiveMQMessage.doBeforeReceive(ActiveMQMessage.java:786) > at > org.apache.activemq.artemis.jms.client.ActiveMQTextMessage.doBeforeReceive(ActiveMQTextMessage.java:110) > at > org.apache.activemq.artemis.ra.inflow.ActiveMQMessageHandler.onMessage(ActiveMQMessageHandler.java:295) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1001) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:49) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1124) > at > org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:748) > {code} > This can be fixed by adjusting default values for these parameters. > In this case, we need more client threads than JCA RA sessions (maxSession). > To avoid resource starvation, number of client threads must be greater than sum of {{maxSession}} for each MDB deployed on server. > We should check number of client threads required by deployments (MDBs), and at least print warning message that size of client thread pool may be insufficient. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-1422) Add possibility to disable channel binding in Elytron clients

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1422?page=com.atlassian.jira.plugin.s... ] Jan Kalina commented on ELY-1422: --------------------------------- Prepared reproducer: https://github.com/honza889/elytron-client-demo/tree/JBEAP-12894-reproducer > Add possibility to disable channel binding in Elytron clients > ------------------------------------------------------------- > > Key: ELY-1422 > URL: https://issues.jboss.org/browse/ELY-1422 > Project: WildFly Elytron > Issue Type: Feature Request > Components: SASL > Affects Versions: 1.2.0.Beta7 > Reporter: Jan Kalina > Assignee: Jan Kalina > > Add Elytron client option to disable channel binding so non-PLUS (SCRAM) mechanisms can be used even if the SSL context is configured for the underlying remoting connection. > This is a follow up jira to JBEAP-12231 (and transitively JBEAP-11396) - look for full discussion there. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9554) Test case for WFCORE-3416 - User redirected with HTTP 301 instead of 302 in admin-only mode

by Tomas Hofman (JIRA)

[ https://issues.jboss.org/browse/WFLY-9554?page=com.atlassian.jira.plugin.... ] Tomas Hofman reassigned WFLY-9554: ---------------------------------- Assignee: Tomas Hofman > Test case for WFCORE-3416 - User redirected with HTTP 301 instead of 302 in admin-only mode > ------------------------------------------------------------------------------------------- > > Key: WFLY-9554 > URL: https://issues.jboss.org/browse/WFLY-9554 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Tomas Hofman > Assignee: Tomas Hofman > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9554) Test case for WFCORE-3416 - User redirected with HTTP 301 instead of 302 in admin-only mode

by Tomas Hofman (JIRA)

Tomas Hofman created WFLY-9554: ---------------------------------- Summary: Test case for WFCORE-3416 - User redirected with HTTP 301 instead of 302 in admin-only mode Key: WFLY-9554 URL: https://issues.jboss.org/browse/WFLY-9554 Project: WildFly Issue Type: Bug Components: Test Suite Reporter: Tomas Hofman -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 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 November 2017