October 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-11237) Eliminate ServiceBuilder's deprecated methods usages

by Richard Opalka (Jira)

[ https://issues.jboss.org/browse/WFLY-11237?page=com.atlassian.jira.plugin... ] Richard Opalka updated WFLY-11237: ---------------------------------- Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/11792) > Eliminate ServiceBuilder's deprecated methods usages > ----------------------------------------------------- > > Key: WFLY-11237 > URL: https://issues.jboss.org/browse/WFLY-11237 > Project: WildFly > Issue Type: Enhancement > Reporter: Richard Opalka > Assignee: Richard Opalka > Priority: Major > Fix For: 15.0.0.Alpha1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-11239) Rewrite SAR subsystem to don't use deprecated ServiceBuilder methods

by Richard Opalka (Jira)

[ https://issues.jboss.org/browse/WFLY-11239?page=com.atlassian.jira.plugin... ] Richard Opalka updated WFLY-11239: ---------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/11792 > Rewrite SAR subsystem to don't use deprecated ServiceBuilder methods > -------------------------------------------------------------------- > > Key: WFLY-11239 > URL: https://issues.jboss.org/browse/WFLY-11239 > Project: WildFly > Issue Type: Sub-task > Components: Server > Reporter: Richard Opalka > Assignee: Richard Opalka > Priority: Major > Fix For: 15.0.0.Alpha1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SWSQE-464) Ansible Failures 2.7

by Guilherme Baufaker Rêgo (Jira)

[ https://issues.jboss.org/browse/SWSQE-464?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo resolved SWSQE-464. ------------------------------------------- Resolution: Done > Ansible Failures 2.7 > -------------------- > > Key: SWSQE-464 > URL: https://issues.jboss.org/browse/SWSQE-464 > Project: Kiali QE > Issue Type: Bug > Reporter: Hayk Hovsepyan > Assignee: Guilherme Baufaker Rêgo > Priority: Blocker > Attachments: install_bookinfo.log, istio_upstream.log > > > Failing with different param runs: > http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/install-bookinfo... > http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/install-bookinfo... > http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/install-bookinfo... -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SWSQE-464) Ansible Failures 2.7

by Guilherme Baufaker Rêgo (Jira)

[ https://issues.jboss.org/browse/SWSQE-464?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo commented on SWSQE-464: ----------------------------------------------- Fixed the complex-mesh job. In future, if we need to switch to Ansible 2.7, we can use this as standard for us. > Ansible Failures 2.7 > -------------------- > > Key: SWSQE-464 > URL: https://issues.jboss.org/browse/SWSQE-464 > Project: Kiali QE > Issue Type: Bug > Reporter: Hayk Hovsepyan > Assignee: Guilherme Baufaker Rêgo > Priority: Blocker > Attachments: install_bookinfo.log, istio_upstream.log > > > Failing with different param runs: > http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/install-bookinfo... > http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/install-bookinfo... > http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/install-bookinfo... -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SWSQE-474) Update Upstream Pipeline To Support Istio 1.0.3

by Guilherme Baufaker Rêgo (Jira)

[ https://issues.jboss.org/browse/SWSQE-474?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo reassigned SWSQE-474: --------------------------------------------- Assignee: Guilherme Baufaker Rêgo (was: Michael Foley) > Update Upstream Pipeline To Support Istio 1.0.3 > ----------------------------------------------- > > Key: SWSQE-474 > URL: https://issues.jboss.org/browse/SWSQE-474 > Project: Kiali QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Guilherme Baufaker Rêgo > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SWSQE-474) Update Upstream Pipeline To Support Istio 1.0.3

by Matt Mahoney (Jira)

Matt Mahoney created SWSQE-474: ---------------------------------- Summary: Update Upstream Pipeline To Support Istio 1.0.3 Key: SWSQE-474 URL: https://issues.jboss.org/browse/SWSQE-474 Project: Kiali QE Issue Type: Task Reporter: Matt Mahoney Assignee: Michael Foley -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2312) LazyThreadFactory can keep threads instances alive for a long period

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/JGRP-2312?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on JGRP-2312: ------------------------------------ I'd argue that `LazyThreadFactory` shouldn't keep track of started threads at all, at least not after `TP` initialization. > LazyThreadFactory can keep threads instances alive for a long period > -------------------------------------------------------------------- > > Key: JGRP-2312 > URL: https://issues.jboss.org/browse/JGRP-2312 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.15 > Reporter: William Burns > Assignee: Bela Ban > Priority: Major > > The LazyThreadFactory keeps all Thread objects in a ConcurrentLinkedQueue wrapped by a WeakReference. This means that once a thread terminates, its instance along with all native memory required for it can linger until the GC eventually reclaims it. Normally this is not an issue when the JVM heap is being recycled often, but in cases where you have low heap requirement operations (ie. off heap data container) this can cause these objects to pile up and eventually exhaust native memory. > This queue is also a very slow JVM heap leak as threads are tossed out, since the WeakReference and Queue Node objects are never reclaimed unless the transport is stopped. > The best way to fix this would be to plug into when the thread is set to TERMINATED state and to remove these nodes. > Also a workaround is to increase the core thread count and increase the keepalive timeout so that threads are not destroyed and created nearly as often. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2312) LazyThreadFactory can keep threads instances alive for a long period

by Dan Berindei (Jira)

[ https://issues.jboss.org/browse/JGRP-2312?page=com.atlassian.jira.plugin.... ] Dan Berindei edited comment on JGRP-2312 at 10/30/18 3:13 PM: -------------------------------------------------------------- I'd argue that `LazyThreadFactory` shouldn't keep track of started threads at all, at least not after {{TP}} initialization. was (Author: dan.berindei): I'd argue that `LazyThreadFactory` shouldn't keep track of started threads at all, at least not after `TP` initialization. > LazyThreadFactory can keep threads instances alive for a long period > -------------------------------------------------------------------- > > Key: JGRP-2312 > URL: https://issues.jboss.org/browse/JGRP-2312 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.15 > Reporter: William Burns > Assignee: Bela Ban > Priority: Major > > The LazyThreadFactory keeps all Thread objects in a ConcurrentLinkedQueue wrapped by a WeakReference. This means that once a thread terminates, its instance along with all native memory required for it can linger until the GC eventually reclaims it. Normally this is not an issue when the JVM heap is being recycled often, but in cases where you have low heap requirement operations (ie. off heap data container) this can cause these objects to pile up and eventually exhaust native memory. > This queue is also a very slow JVM heap leak as threads are tossed out, since the WeakReference and Queue Node objects are never reclaimed unless the transport is stopped. > The best way to fix this would be to plug into when the thread is set to TERMINATED state and to remove these nodes. > Also a workaround is to increase the core thread count and increase the keepalive timeout so that threads are not destroyed and created nearly as often. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-11259) Wildfly 11.0.0.Final org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory

by Adam Bialas (Jira)

Adam Bialas created WFLY-11259: ---------------------------------- Summary: Wildfly 11.0.0.Final org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory Key: WFLY-11259 URL: https://issues.jboss.org/browse/WFLY-11259 Project: WildFly Issue Type: Bug Affects Versions: 11.0.0.Final Reporter: Adam Bialas Assignee: Jason Greene I have an ear file which I want to deploy to the Wildfly 11.0.0.Final. In this ear file in the lib folder I have dom4j-2.0.1.jar. One of the sub deployments (war) uses JPA (no dependencies to hibernate, just to javax.javaee-api as compile only). This sub deployment contains of course the persistence.xml file. I see in the logs that when the application server starts and loads this file the following exception is thrown: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory and the application fails to deploy. I checked many posts and forums on the net and as far as I understand I must exclude the dom4j provided by the application server so the jar located in the lib folder of ear can be used. I created jboss-deployment-structure: <?xml version="1.0" encoding="UTF-8"?> <jboss-deployment-structure> <deployment> <exclusions> <module name="org.dom4j"/> </exclusions> </deployment> </jboss-deployment-structure> Even though I get the same exception so I suppose both jars are loaded and cause problems. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-3185) [DMN Designer] Change Literal Expression to Decision Table

by Matteo Mortari (Jira)

[ https://issues.jboss.org/browse/DROOLS-3185?page=com.atlassian.jira.plugi... ] Matteo Mortari commented on DROOLS-3185: ---------------------------------------- Sorry [~jomarko] I am not sure I understand this latest question. Can you provide an example, please? (Of what to differentiate, the DMN file I can see but I don't understand the editor use case you refer to) > [DMN Designer] Change Literal Expression to Decision Table > ---------------------------------------------------------- > > Key: DROOLS-3185 > URL: https://issues.jboss.org/browse/DROOLS-3185 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.14.0.Final > Reporter: Jozef Marko > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > Fix For: 7.14.0.Final > > Attachments: Screenshot from 2018-10-25 14-40-06.png, Screenshot from 2018-10-29 12-25-14.png, Screenshot from 2018-10-29 12-25-31.png, a1.dmn, a2.dmn, screenshot-1.png > > > When user changes Decision node top level expression from literal expression to decision table, that decision table misses InputClause columns. > h2. Manual Acceptance Test > Check steps to reproduce, while InputData node has data type > - Built in type (/) > - Custom type that has constraint (/) > - Custom type that is collection (?) > - Custom type that is recursive (/) > - Multiple InputData nodes (/) > - -Multiple input nodes, mixed InputData and Decision- doesn't work, not supported -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

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 October 2018