May 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2423) Elytron resources runtime updates without reload

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2423?page=com.atlassian.jira.plugi... ] Jan Kalina commented on WFCORE-2423: ------------------------------------ [~treblereel] as discussed in WFCORE-1953, this issue should be rejected. > Elytron resources runtime updates without reload > ------------------------------------------------ > > Key: WFCORE-2423 > URL: https://issues.jboss.org/browse/WFCORE-2423 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > Assignee: Dmitrii Tikhomirov > > When updating elytron resources, server ends up in {{reload-required}} state. For example > {code} > [standalone@localhost:9990 /] /subsystem=elytron/kerberos-security-factory=krbSF:write-attribute(name=debug, value=true) > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > {code} > Make it possible for all (most - some may be impossible) resources to support runtime updates. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-271) Istio Downstream install from Template

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-271?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo edited comment on SWSQE-271 at 5/30/18 3:32 PM: ------------------------------------------------------------------------ Hi Hayk, I kind of started of SWSQE-264... is that similar to that one? was (Author: gbaufake): Hi Hayk, I kind of started of #264... is that similar to that one? > Istio Downstream install from Template > -------------------------------------- > > Key: SWSQE-271 > URL: https://issues.jboss.org/browse/SWSQE-271 > Project: Kiali QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > > https://github.com/openshift-istio/openshift-ansible/blob/istio-3.9-0.7.1... > Install Kiali over that. > Run Kiali UI/REST Automation tests. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-271) Istio Downstream install from Template

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-271?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo commented on SWSQE-271: ----------------------------------------------- Hi Hayk, I kind of started of #264... is that similar to that one? > Istio Downstream install from Template > -------------------------------------- > > Key: SWSQE-271 > URL: https://issues.jboss.org/browse/SWSQE-271 > Project: Kiali QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > > https://github.com/openshift-istio/openshift-ansible/blob/istio-3.9-0.7.1... > Install Kiali over that. > Run Kiali UI/REST Automation tests. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8858) Remove JPA container check for deprecated hibernate.ejb.use_class_enhancer

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-8858?page=com.atlassian.jira.plugin.... ] Scott Marlow closed WFLY-8858. ------------------------------ Resolution: Rejected > Remove JPA container check for deprecated hibernate.ejb.use_class_enhancer > -------------------------------------------------------------------------- > > Key: WFLY-8858 > URL: https://issues.jboss.org/browse/WFLY-8858 > Project: WildFly > Issue Type: Task > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 14.0.0.CR1 > > > Applications can instead use the jboss.as.jpa.classtransformer property to control whether the application can use entity class rewriting. Starting with Hibernate ORM 5.0+, Hibernate defaults to always rewrite entity classes. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8858) Remove JPA container check for deprecated hibernate.ejb.use_class_enhancer

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-8858?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-8858: ------------------------------------ >From [http://lists.jboss.org/pipermail/hibernate-dev/2018-May/017693.html] conversation that [~gbadner] started (thank you!). Question from the discussion: {quote} In the past, I recall someone mentioning that lazy loading or dirty flag handling, would depend on bytecode enhancing. If that happened or will happen, we should discuss what the fallback solution is for when bytecode enhancing is not working. {quote} Response: {quote} Bytecode enhancement is not needed for either of these - Hibernate can (and has forever) supported these without enhancement. That will continue to be the case. Bytecode enhancement is simply an alternative means for adding these features. However, certain features such as automatic bi-dir association management does require enhancement to work. {quote} See above linked discussion for more details. It seems to me that we don't need to fix anything in WildFly for [WFLY-8858], at least not now. So, will close. > Remove JPA container check for deprecated hibernate.ejb.use_class_enhancer > -------------------------------------------------------------------------- > > Key: WFLY-8858 > URL: https://issues.jboss.org/browse/WFLY-8858 > Project: WildFly > Issue Type: Task > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 14.0.0.CR1 > > > Applications can instead use the jboss.as.jpa.classtransformer property to control whether the application can use entity class rewriting. Starting with Hibernate ORM 5.0+, Hibernate defaults to always rewrite entity classes. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10426) Drop usage of JpaAttachments#TRANSACTION_MANAGER and #TSR

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-10426?page=com.atlassian.jira.plugin... ] Scott Marlow updated WFLY-10426: -------------------------------- Fix Version/s: 14.0.0.CR1 > Drop usage of JpaAttachments#TRANSACTION_MANAGER and #TSR > --------------------------------------------------------- > > Key: WFLY-10426 > URL: https://issues.jboss.org/browse/WFLY-10426 > Project: WildFly > Issue Type: Task > Components: JPA / Hibernate > Reporter: David Lloyd > Assignee: Scott Marlow > Fix For: 14.0.0.CR1 > > > Since the WildFly Transaction Client is responsible for coordinating between WildFly and the backing TM implementation, the attachments {{JpaAttachments#TRANSACTION_MANAGER}} and {{JpaAttachments#TRANSACTION_SYNCHRONIZATION_REGISTRY}} are no longer needed and all usages can be replaced with simple calls to {{ContextTransactionManager.getInstance()}} and {{ContextTransactionSynchronizationRegistry.getInstance()}}. > Note that deployment dependencies (such as those established in {{PersistenceUnitParseProcessor#deploy}}) are presently still required (to ensure that the TM is available before starting the deployment), but the value can be discarded. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10485) Distributed web sessions fail to replicate if Undertow configured with custom session ID alphabet

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-10485: ----------------------------------- Summary: Distributed web sessions fail to replicate if Undertow configured with custom session ID alphabet Key: WFLY-10485 URL: https://issues.jboss.org/browse/WFLY-10485 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 13.0.0.Beta1 Reporter: Paul Ferraro Assignee: Paul Ferraro The wildfly-clustering-web-undertow module currently assumes that session IDs generated by Undertow are marshallable using Base64.getUrlDecoder(). Undertow 2.0.x added support for customizing the alphabet using a system property. Any user doing so will be unable to use distributed web session manager, as the generated session IDs will fail to marshal at runtime. At the very least, we should detect the use of this system property and disable the session ID marshalling optimization. At most, we can adapt the marshalling optimization to use the custom alphabet. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9849) Hibernate session related leak on module undeployment

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-9849?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-9849: ------------------------------------ I'm currently looking at wildfly-leak-2.hprof with the [https://www.eclipse.org/mat/] tool. In the Histogram view, I filtered on the name of the leaked class "org.hibernate.internal.SessionFactoryImpl" and see that we have four objects with name=HibernateTestPU: {code} Class Name | Objects | Shallow Heap | Retained Heap ------------------------------------------------------------------------------------------------------ org.hibernate.internal.SessionFactoryImpl$3 | 0 | 0 | org.hibernate.internal.SessionFactoryImpl$2 | 0 | 0 | org.hibernate.internal.SessionFactoryImpl$1IntegratorObserver| 4 | 96 | >= 416 org.hibernate.internal.SessionFactoryImpl$1 | 0 | 0 | org.hibernate.internal.SessionFactoryImpl | 4 | 544 | >= 797,032 ------------------------------------------------------------------------------------------------------ {code} One of the paths to SessionFactoryImpl shows: {code} Class Name | Ref. Objects | Shallow Heap | Ref. Shallow Heap | Retained Heap ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- org.jboss.msc.service.ServiceContainerImpl$ServiceThread @ 0xe0103d28 MSC service thread 1-5 Thread | 1 | 128 | 136 | 4,168 '- container org.jboss.msc.service.ServiceContainerImpl @ 0xe0486e20 | 1 | 104 | 136 | 26,576 '- registry java.util.concurrent.ConcurrentHashMap @ 0xe0487078 | 1 | 64 | 136 | 25,408 '- table java.util.concurrent.ConcurrentHashMap$Node[1024] @ 0xe06a5cb8 | 1 | 4,112 | 136 | 25,328 '- [820] java.util.concurrent.ConcurrentHashMap$Node @ 0xe1059098 | 1 | 32 | 136 | 64 '- next java.util.concurrent.ConcurrentHashMap$Node @ 0xe17b8638 | 1 | 32 | 136 | 32 '- val org.jboss.msc.service.ServiceRegistrationImpl @ 0xe13da8a8 | 1 | 40 | 136 | 104 '- instance org.jboss.msc.service.ServiceControllerImpl @ 0xe194f4c8 | 1 | 120 | 136 | 912 '- serviceValue org.jboss.msc.value.ImmediateValue @ 0xe194f540 | 1 | 16 | 136 | 16 '- value org.jboss.as.jpa.service.PersistenceUnitServiceImpl @ 0xe194f550 | 1 | 80 | 136 | 424 '- entityManagerFactory org.hibernate.jpa.internal.EntityManagerFactoryImpl @ 0xe194f9b8| 1 | 56 | 136 | 5,728 '- sessionFactory org.hibernate.internal.SessionFactoryImpl @ 0xe18b84c0 | 1 | 136 | 136 | 122,728 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- {code} It seems like the org.jboss.as.jpa.service.PersistenceUnitServiceImpl that references the HibernateTestPU didn't getting stopped at undeployment time. Could you please try [enabling TRACE logging for org.jboss.as.jpa|http://docs.wildfly.org/12/Developer_Guide.html#troubles...] and attach the standalone/log/server.log that shows application deployment and undeployment of the HibernateLeakTest jar. I'm looking to see if an error occurred during undeployment that might help us understand what happened. > Hibernate session related leak on module undeployment > ----------------------------------------------------- > > Key: WFLY-9849 > URL: https://issues.jboss.org/browse/WFLY-9849 > Project: WildFly > Issue Type: Bug > Affects Versions: 11.0.0.Final, 12.0.0.Final > Environment: * Ubuntu 16.04.3 LTS > * OpenJDK 1.8.0_151 > * Wildfly 11.0.0.Final > Seems to occur at least on CentOS 7/OpenJDK 1.8.0_151 also. > Reporter: Joni Syri > Assignee: Scott Marlow > > In some cases it seems that removing deployment from the Wildfly, doesn't free up {{org.hibernate.internal.SessionFactoryImpl}}- instance related to the deployment. (plus some other Hibernate related classes). This can be seen by taking memory dump with VisualVM and looking up {{SessionFactoryImpl}} instances. > This leads to cumulative memory leak in cases, where application is repeatedly deployed/undeployed (or updated). > updated: Seems to occur on 12.0.0.Final also > Memory dumps can be found at https://drive.google.com/drive/folders/1WbHB6hRpr_lrc4yb4yxWLpeObmJlNCzD (wildfly-leak-1 is after first deployment, wildfly-leak-2 after few re-deploys) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2604) Inappropriate behavior/logging after kjar deployment to the kie server

by Igor Azarny (JIRA)

Igor Azarny created DROOLS-2604: ----------------------------------- Summary: Inappropriate behavior/logging after kjar deployment to the kie server Key: DROOLS-2604 URL: https://issues.jboss.org/browse/DROOLS-2604 Project: Drools Issue Type: Feature Request Components: kie server Affects Versions: 7.7.0.Final Reporter: Igor Azarny Assignee: Edson Tirelli A lot of attempts to create different class instance after deployment of kjar to the kie server. I hardly think, that com.couchbase.client.deps.io.netty.handler.ssl.Java9SslUtils$5 or other classes somehow related to deployed KJar. Is it "by design" or unexpected behavior? 2018-05-30T17:35:44.83+0300 [APP/PROC/WEB/0] OUT [CONTAINER] ie.server.services.drools.DroolsKieServerExtension WARNING Unable to create instance of type org.apache.lucene.search.join.TermsIncludingScoreQuery$1 due to org.apache.lucene.search.join.TermsIncludingScoreQuery$1 ..... 2018-05-30T17:43:31.07+0300 [APP/PROC/WEB/0] OUT [CONTAINER] ie.server.services.drools.DroolsKieServerExtension WARNING Unable to create instance of type com.couchbase.client.deps.io.netty.handler.ssl.Java9SslUtils$6 due to com.couchbase.client.deps.io.netty.handler.ssl.Java9SslUtils$6 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8431) Race conditions in JASPIC registration code

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/WFLY-8431?page=com.atlassian.jira.plugin.... ] Ilia Vassilev updated WFLY-8431: -------------------------------- Git Pull Request: https://github.com/jboss/jboss-jaspi-api_spec/pull/4, https://github.com/picketbox/picketbox/pull/68 (was: https://github.com/jboss/jboss-jaspi-api_spec/pull/4) > Race conditions in JASPIC registration code > ------------------------------------------- > > Key: WFLY-8431 > URL: https://issues.jboss.org/browse/WFLY-8431 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.1.0.Final > Environment: Centos 7 x86_64, with the included Java 8 environment > Reporter: István Tóth > Assignee: Darran Lofthouse > Attachments: GetFactoryTestCase.java > > > javax.security.auth.message.config.AuthConfigFactory and > org.jboss.security.auth.message.config.JBossAuthConfigFactory > have race conditions. > 1. javax.security.auth.message.config.AuthConfigFactory#getFactory() has a race condition. The checking and creation of the _factory object is not atomic. > I think the best and simplest solution would be to simply make the getFactory() method synchronized. (The same method in the Glassfish implmentation is synchronized) > 2. The keyTo*Map fields of the org.jboss.security.auth.message.config.JBossAuthConfigFactory are not thread safe. > Nearly all methods of this class manipulate these, without any synchronization. > In this case I believe that changing those from HashMaps to ConcurrentHashMaps should be enough to avoid the worst of the races, while incurring a negligible performance penalty. > The methods that modify the maps should also be made synchronized, or rewritten to use the > atomic ConcurrentHashMaps operations. > A possible workaround is to add a synchronized(AuthConfigFactory.class) block around the JASPIC initialization code, where the JBossAuthConfigFactory methods are called. Of course this only works if every webapp on the server can be modified this way. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 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 May 2018