[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
[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
[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
[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
[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
[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