January 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9720) org.jboss.as.jpa.hibernate5.management.QueryName.displayable() consumes high amount of CPU

by Osamu Nagano (JIRA)

Osamu Nagano created WFLY-9720: ---------------------------------- Summary: org.jboss.as.jpa.hibernate5.management.QueryName.displayable() consumes high amount of CPU Key: WFLY-9720 URL: https://issues.jboss.org/browse/WFLY-9720 Project: WildFly Issue Type: Bug Components: JPA / Hibernate Reporter: Osamu Nagano Assignee: Scott Marlow JIPI-32 is fixed in the following classes: {code} jpa/hibernate4_1/src/main/java/org/jboss/as/jpa/hibernate4/management/QueryName.java jpa/hibernate4_3/src/main/java/org/jboss/as/jpa/hibernate4/management/QueryName.java {code} But not in the following class: {code} jpa/hibernate5/src/main/java/org/jboss/as/jpa/hibernate5/management/QueryName.java {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3536) Upgrade JBoss modules to 1.7.0.Beta3

by Stuart Douglas (JIRA)

Stuart Douglas created WFCORE-3536: -------------------------------------- Summary: Upgrade JBoss modules to 1.7.0.Beta3 Key: WFCORE-3536 URL: https://issues.jboss.org/browse/WFCORE-3536 Project: WildFly Core Issue Type: Component Upgrade Reporter: Stuart Douglas Assignee: Stuart Douglas This is necessary for the EE8 work to begin -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-132) Support low-metaspace bundles/classes

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-132?page=com.atlassian.jira.plugi... ] James Perkins commented on LOGTOOL-132: --------------------------------------- Do we also have concerns on distribution size? We currently do not ship any of the {{*.properties}} in WildFly and these changes would likely require those to be shipped. That being said the classes themselves will likely be smaller in general. > Support low-metaspace bundles/classes > ------------------------------------- > > Key: LOGTOOL-132 > URL: https://issues.jboss.org/browse/LOGTOOL-132 > Project: Log Tool > Issue Type: Enhancement > Reporter: David Lloyd > Priority: Critical > > Metaspace is at a premium in the application server environment, and the number one consumer is presently generated log classes. > Introduce a leaner variation on generated classes with the following requirements: > * The generated class must be {{final}} > * The generated class must contain no message strings > * The generated class must accept both a {{Logger}} and a {{Locale}}, and load its resources from a file based on that information > * The usage of Java 8's locale lookup functionality should be considered, to support language tags etc.; a helper utility could be introduced into {{jboss-logging}} for this > Here are some implementation ideas: > * Option 1: The resource files contain only messages, one per line, loaded directly into a {{String[]}} instance field in the implementation class; each logging method uses a hard-coded array index to access its message > ** A key advantage is that the implementation class is very small, and consumes very little metaspace; also, it is fast, requiring only an array lookup to acquire the string > ** A disadvantage is, any change to the message set invalidates all the locale files, which must then be regenerated > ** Also, each locale file must contain all messages, unless a fallback mechanism is used (e.g. an empty line signifies that the string should come from the parent locale) > * Option 2: The resource files contain key-value pairs, with the key being equal to the method name > ** Advantage: the file is not invalidated if a key is added, and sub-locales can inherit more easily from parent locales > ** Disadvantage: the added overhead of mapping lines to methods (for example, using a switch statement to map method names to fixed indexes, or loading the messages into a hash table e.g. {{HashMap}}) will fill metaspace or impact performance, or both -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3535) TEST, TO DELETE

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3535?page=com.atlassian.jira.plugi... ] Jean-Francois Denise deleted WFCORE-3535: ----------------------------------------- > TEST, TO DELETE > --------------- > > Key: WFCORE-3535 > URL: https://issues.jboss.org/browse/WFCORE-3535 > Project: WildFly Core > Issue Type: Feature Request > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3535) TEST, TO DELETE

by Jean-Francois Denise (JIRA)

Jean-Francois Denise created WFCORE-3535: -------------------------------------------- Summary: TEST, TO DELETE Key: WFCORE-3535 URL: https://issues.jboss.org/browse/WFCORE-3535 Project: WildFly Core Issue Type: Feature Request Components: CLI Reporter: Jean-Francois Denise Assignee: Jean-Francois Denise -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9719) ProxyListValidator should not do DNS validation

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-9719: ------------------------------------ Summary: ProxyListValidator should not do DNS validation Key: WFLY-9719 URL: https://issues.jboss.org/browse/WFLY-9719 Project: WildFly Issue Type: Bug Components: mod_cluster Reporter: Stuart Douglas Assignee: Stuart Douglas -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2234) Unlocked locks stay locked forever

by David White (JIRA)

[ https://issues.jboss.org/browse/JGRP-2234?page=com.atlassian.jira.plugin.... ] David White commented on JGRP-2234: ----------------------------------- Wow - I'm glad someone else has run into this issue and has been able to replicate a stand-alone test case. I too was desperately trying to figure out if this was just a configuration issue, or a bug in JGroups. We have a 5 node cluster using the CENTRAL_LOCK with the Lock Service and one backup node. All 5 nodes are competing for access for the same resource to lock. We see a similar scenario where if the Coordinator and backup nodes leave the cluster, sometimes the unlock request from a node is "successfully" processed but yet a dirty lock state is transferred to the node becoming the new coordinator. Subsequently, that resource is permanently locked. It looks like Bela has fixed this in version 4.0.10. Hopefully, our issue is the same one that has now been fixed. > Unlocked locks stay locked forever > ---------------------------------- > > Key: JGRP-2234 > URL: https://issues.jboss.org/browse/JGRP-2234 > Project: JGroups > Issue Type: Bug > Reporter: Bram Klein Gunnewiek > Assignee: Bela Ban > Fix For: 4.0.10 > > Attachments: ClusterSplitLockTest.java, jg_clusterlock_output_testfail.txt > > > As discussed in the mailing list we have issues where locks from the central lock protocol stay locked forever when the coordinator of the cluster disconnects. We can reproduce this with the attached ClusterSplitLockTest.java. Its a race condition and we need to run the test a lot of times (sometimes > 20) before we encounter a failure. > What we think is happening: > In a three node cluster (node A, B and C where node A is the coordinator) unlock requests from B and/or C can be missed when node A leaves and B and/or C don't have the new view installed yet. When, for example, node B takes over coordination it creates the lock table based on the back-ups. Lets say node C has locked the lock with name 'lockX'. Node C performs an unlock of 'lockX' just after node A (gracefully) leaves and sends the unlock request to node A since node C doesn't have the correct view installed yet. Node B has and recreated the lock table where 'lockX' is locked by Node C. Node C doesn't resend the unlock request so 'lockX' gets locked forever. > Attached is the testng test we wrote and the output of a test failure. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9714) Configuring Server cipher order in JBoss 7.1.0 AS

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-9714?page=com.atlassian.jira.plugin.... ] Martin Choma commented on WFLY-9714: ------------------------------------ WFLY 11, EAP 7.1 > Configuring Server cipher order in JBoss 7.1.0 AS > -------------------------------------------------- > > Key: WFLY-9714 > URL: https://issues.jboss.org/browse/WFLY-9714 > Project: WildFly > Issue Type: Feature Request > Components: Security > Affects Versions: JBoss AS7 7.1.1.Final > Environment: All operating systems. > Reporter: pavan dittakavi > Assignee: Darran Lofthouse > > Hello Everyone, looks like the JBoss 7.1.0 AS Final version does not have an option to fix the cipher order that is determined by the server. In other words, the SSLHonorCipherOrder attribute does not work. > https://developer.jboss.org/thread/276787 > Request you to add this feature. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9714) Configuring Server cipher order in JBoss 7.1.0 AS

by pavan dittakavi (JIRA)

[ https://issues.jboss.org/browse/WFLY-9714?page=com.atlassian.jira.plugin.... ] pavan dittakavi commented on WFLY-9714: --------------------------------------- Thanks guys. Can you please tell us which JBoss EAP version would help us in having this feature?. This is becoming very crucial to us and so we wanted to know if this is already addressed in an JBoss EAP version. Please share your views. > Configuring Server cipher order in JBoss 7.1.0 AS > -------------------------------------------------- > > Key: WFLY-9714 > URL: https://issues.jboss.org/browse/WFLY-9714 > Project: WildFly > Issue Type: Feature Request > Components: Security > Affects Versions: JBoss AS7 7.1.1.Final > Environment: All operating systems. > Reporter: pavan dittakavi > Assignee: Darran Lofthouse > > Hello Everyone, looks like the JBoss 7.1.0 AS Final version does not have an option to fix the cipher order that is determined by the server. In other words, the SSLHonorCipherOrder attribute does not work. > https://developer.jboss.org/thread/276787 > Request you to add this feature. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2217) [DMN Editor] Allow DMN persistence for an incomplete, still being authored, DMN model

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2217?page=com.atlassian.jira.plugi... ] Matteo Mortari commented on DROOLS-2217: ---------------------------------------- with the premise than from XSD and the spec: - a context entry must have a "value", being an expression on DMN side: consider a LiteralExpression with "text" being null, as a special case representing a missing expression altogether on Stunner side: use null to represent missing expression, when there should be one > [DMN Editor] Allow DMN persistence for an incomplete, still being authored, DMN model > ------------------------------------------------------------------------------------- > > Key: DROOLS-2217 > URL: https://issues.jboss.org/browse/DROOLS-2217 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.6.0.Final > Reporter: Jozef Marko > Assignee: Matteo Mortari > Attachments: Screenshot from 2018-01-22 14-01-38.png, Screenshot from 2018-01-22 14-02-13.png, error.log > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 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 January 2018