April 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2469) GossipRouter: make GraalVM-compliant

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2469?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-2469: -------------------------------- Added an {{init()}} method. Called by {{start()}} if user forgot to call it explictly. The builder idea creates duplicate code (all attrs), so I rejected it. > GossipRouter: make GraalVM-compliant > ------------------------------------ > > Key: JGRP-2469 > URL: https://issues.redhat.com/browse/JGRP-2469 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.0.0.Alpha5 > > > Currently, GossipRouter starts threads in the constructor. This prohibits it to run under GraalVM as a native image, as threads cannot be started at build time. > Create a separate method {{init()}}, which is called after the constructor and after all attributes have been set, but before {{start()}}. > Alternative: use a builder: > {code:java} > router=GossipRouter.builder().setXX().build(); // creates server > router.start(); > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2469) GossipRouter: make GraalVM-compliant

by Bela Ban (Jira)

Bela Ban created JGRP-2469: ------------------------------ Summary: GossipRouter: make GraalVM-compliant Key: JGRP-2469 URL: https://issues.redhat.com/browse/JGRP-2469 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Fix For: 5.0.0.Alpha5 Currently, GossipRouter starts threads in the constructor. This prohibits it to run under GraalVM as a native image, as threads cannot be started at build time. Create a separate method {{init()}}, which is called after the constructor and after all attributes have been set, but before {{start()}}. Alternative: use a builder: {code:java} router=GossipRouter.builder().setXX().build(); // creates server router.start(); {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5250) [Scesim editor] Wrong context type scesim generation

by Anna Dupliak (Jira)

[ https://issues.redhat.com/browse/DROOLS-5250?page=com.atlassian.jira.plug... ] Anna Dupliak commented on DROOLS-5250: -------------------------------------- [~yamer] Thanks for noticing moved to DROOLS > [Scesim editor] Wrong context type scesim generation > ----------------------------------------------------- > > Key: DROOLS-5250 > URL: https://issues.redhat.com/browse/DROOLS-5250 > Project: Drools > Issue Type: Bug > Components: Test Scenarios Editor > Affects Versions: 7.37.0.Final > Reporter: Anna Dupliak > Assignee: Yeser Amer > Priority: Major > Labels: drools-tools > Fix For: 7.37.0.Final > > Attachments: TestPossible types.dmn, image-2020-04-03-11-47-11-708.png > > > When I create a data type in dmn like: > -tDriver (Structure) > --tNested (Structure) > ---nested (string) > --contextType(context) > Then fact is generated as tNested.contextType.value but expect contextType.value > !image-2020-04-03-11-47-11-708.png|thumbnail! -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5250) [Scesim editor] Wrong context type scesim generation

by Anna Dupliak (Jira)

[ https://issues.redhat.com/browse/DROOLS-5250?page=com.atlassian.jira.plug... ] Anna Dupliak moved KOGITO-1685 to DROOLS-5250: ---------------------------------------------- Project: Drools (was: Kogito) Key: DROOLS-5250 (was: KOGITO-1685) Docs QE Status: NEW Component/s: Test Scenarios Editor (was: Scenario Simulation) Affects Version/s: 7.37.0.Final (was: Kogito Tooling 0.2.9) QE Status: NEW Fix Version/s: 7.37.0.Final (was: Kogito Tooling 0.4.1) > [Scesim editor] Wrong context type scesim generation > ----------------------------------------------------- > > Key: DROOLS-5250 > URL: https://issues.redhat.com/browse/DROOLS-5250 > Project: Drools > Issue Type: Bug > Components: Test Scenarios Editor > Affects Versions: 7.37.0.Final > Reporter: Anna Dupliak > Assignee: Yeser Amer > Priority: Major > Labels: drools-tools > Fix For: 7.37.0.Final > > Attachments: TestPossible types.dmn, image-2020-04-03-11-47-11-708.png > > > When I create a data type in dmn like: > -tDriver (Structure) > --tNested (Structure) > ---nested (string) > --contextType(context) > Then fact is generated as tNested.contextType.value but expect contextType.value > !image-2020-04-03-11-47-11-708.png|thumbnail! -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4424) [DMN Designer] Copy of BKM node throws an error

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4424?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4424: -------------------------------- Description: User can create a diagram node copy by standard key compination *Ctrl+C* and *Ctrl+V*. The issue is if a BKM node is copied in this way. Then if user navigates into expression editor of the copied node there are two issues: # The content is not copied # Any attempt to define an expression type throws an error, see the attachement h2. Acceptance test https://github.com/kiegroup/kie-wb-common/pull/3272 was: User can create a diagram node copy by standard key compination *Ctrl+C* and *Ctrl+V*. The issue is if a BKM node is copied in this way. Then if user navigates into expression editor of the copied node there are two issues: # The content is not copied # Any attempt to define an expression type throws an error, see the attachement > [DMN Designer] Copy of BKM node throws an error > ----------------------------------------------- > > Key: DROOLS-4424 > URL: https://issues.redhat.com/browse/DROOLS-4424 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.25.0.Final, 7.36.0.Final > Reporter: Jozef Marko > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > Attachments: Screenshot from 2019-08-12 09-31-02.png > > > User can create a diagram node copy by standard key compination *Ctrl+C* and *Ctrl+V*. The issue is if a BKM node is copied in this way. Then if user navigates into expression editor of the copied node there are two issues: > # The content is not copied > # Any attempt to define an expression type throws an error, see the attachement > h2. Acceptance test > https://github.com/kiegroup/kie-wb-common/pull/3272 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13386) Hung process instances and associated server.log WARN "Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' "

by Enrique González Martínez (Jira)

[ https://issues.redhat.com/browse/WFLY-13386?page=com.atlassian.jira.plugi... ] Enrique González Martínez reassigned WFLY-13386: ------------------------------------------------ Assignee: Enrique González Martínez (was: Brian Stansberry) > Hung process instances and associated server.log WARN "Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' " > ---------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-13386 > URL: https://issues.redhat.com/browse/WFLY-13386 > Project: WildFly > Issue Type: Bug > Reporter: Enrique González Martínez > Assignee: Enrique González Martínez > Priority: Major > > When a timer is reloaded for the first time in other node there are no listeners attached to it causing this problem (only in cluster environments with db timers) > {code} > 2020-04-15 16:43:57,733 WARN [org.jboss.as.ejb3.timer] (Timer-1) WFLYEJB0161: Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' (id=33170e5f-3b34-4503-8796-9b5e6871c074) from its persistent state: java.lang.NullPointerException > at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence$RefreshTask.run(DatabaseTimerPersistence.java:851) > at java.util.TimerThread.mainLoop(Timer.java:555) > at java.util.TimerThread.run(Timer.java:505) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9278) EJB Access Timeout is ignored on SFSBs when using distributed caches

by Tomasz Adamski (Jira)

[ https://issues.redhat.com/browse/WFLY-9278?page=com.atlassian.jira.plugin... ] Tomasz Adamski resolved WFLY-9278. ---------------------------------- Resolution: Out of Date > EJB Access Timeout is ignored on SFSBs when using distributed caches > -------------------------------------------------------------------- > > Key: WFLY-9278 > URL: https://issues.redhat.com/browse/WFLY-9278 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 11.0.0.CR1 > Reporter: Bernhard Hablesreiter > Assignee: Tomasz Adamski > Priority: Major > Attachments: wildfly-request-test.zip > > > When using distributed caches on Stateful Session Beans, the configured access timeout is ignored. However, the caches acquire-timeout is used instead, leading to a "org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after x seconds". > The configuration: > {code:xml} > <session-bean> > <stateless> > <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/> > </stateless> > <stateful default-access-timeout="2000" cache-ref="distributable" passivation-disabled-cache-ref="simple"/> > <singleton default-access-timeout="2000"/> > </session-bean> > <pools> > <bean-instance-pools> > <strict-max-pool name="slsb-strict-max-pool" derive-size="from-worker-pools" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/> > <strict-max-pool name="mdb-strict-max-pool" derive-size="from-cpu-count" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/> > </bean-instance-pools> > </pools> > <caches> > <cache name="simple"/> > <cache name="distributable" passivation-store-ref="infinispan" aliases="passivating clustered"/> > </caches> > ... > <subsystem xmlns="urn:jboss:domain:infinispan:4.0"> > ... > <cache-container name="ejb" aliases="sfsb" default-cache="passivation" module="org.wildfly.clustering.ejb.infinispan"> > <local-cache name="passivation"> > <locking isolation="REPEATABLE_READ" acquire-timeout="10000"/> > <transaction mode="BATCH" /> > <file-store passivation="true" purge="true"/> > </local-cache> > </cache-container> > ... > </subsystem> > {code} > With the above configuration, any access to a @Stateful-component does not timeout after 2 seconds, but the 10 seconds configured on the infinispan-cache. > I have attached a simple JSF web application as an eclipse project to reproduce the problem. The application calls a method on a sfsb, increments a counter and waits for 300ms. If one sends multiple request at the same time (e.g. by pressing F5 repeatedly), the problem can easily be reproduced after a few seconds. > If the cache-ref is set to "simple" the configured access timeout works as expected, however the access to the stateful bean does not appear to be in sync with the requests the client sent. We came around this issue when trying to migrate vom WF9 to WF10 (see also this forum post: https://developer.jboss.org/thread/266303). When the cache-ref is set to "distrubted", the requests are handled correctly/in correct order (in WF9 this was also the case with cache-ref "simple"), but the access timeout is ignored. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9278) EJB Access Timeout is ignored on SFSBs when using distributed caches

by Tomasz Adamski (Jira)

[ https://issues.redhat.com/browse/WFLY-9278?page=com.atlassian.jira.plugin... ] Tomasz Adamski commented on WFLY-9278: -------------------------------------- I can no longer reproduce this error - closing. > EJB Access Timeout is ignored on SFSBs when using distributed caches > -------------------------------------------------------------------- > > Key: WFLY-9278 > URL: https://issues.redhat.com/browse/WFLY-9278 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 11.0.0.CR1 > Reporter: Bernhard Hablesreiter > Assignee: Tomasz Adamski > Priority: Major > Attachments: wildfly-request-test.zip > > > When using distributed caches on Stateful Session Beans, the configured access timeout is ignored. However, the caches acquire-timeout is used instead, leading to a "org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after x seconds". > The configuration: > {code:xml} > <session-bean> > <stateless> > <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/> > </stateless> > <stateful default-access-timeout="2000" cache-ref="distributable" passivation-disabled-cache-ref="simple"/> > <singleton default-access-timeout="2000"/> > </session-bean> > <pools> > <bean-instance-pools> > <strict-max-pool name="slsb-strict-max-pool" derive-size="from-worker-pools" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/> > <strict-max-pool name="mdb-strict-max-pool" derive-size="from-cpu-count" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/> > </bean-instance-pools> > </pools> > <caches> > <cache name="simple"/> > <cache name="distributable" passivation-store-ref="infinispan" aliases="passivating clustered"/> > </caches> > ... > <subsystem xmlns="urn:jboss:domain:infinispan:4.0"> > ... > <cache-container name="ejb" aliases="sfsb" default-cache="passivation" module="org.wildfly.clustering.ejb.infinispan"> > <local-cache name="passivation"> > <locking isolation="REPEATABLE_READ" acquire-timeout="10000"/> > <transaction mode="BATCH" /> > <file-store passivation="true" purge="true"/> > </local-cache> > </cache-container> > ... > </subsystem> > {code} > With the above configuration, any access to a @Stateful-component does not timeout after 2 seconds, but the 10 seconds configured on the infinispan-cache. > I have attached a simple JSF web application as an eclipse project to reproduce the problem. The application calls a method on a sfsb, increments a counter and waits for 300ms. If one sends multiple request at the same time (e.g. by pressing F5 repeatedly), the problem can easily be reproduced after a few seconds. > If the cache-ref is set to "simple" the configured access timeout works as expected, however the access to the stateful bean does not appear to be in sync with the requests the client sent. We came around this issue when trying to migrate vom WF9 to WF10 (see also this forum post: https://developer.jboss.org/thread/266303). When the cache-ref is set to "distrubted", the requests are handled correctly/in correct order (in WF9 this was also the case with cache-ref "simple"), but the access timeout is ignored. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12654) Switch from javax.jws:jsr181-api to jakarta.jws:jakarta.jws-api

by Jim Ma (Jira)

[ https://issues.redhat.com/browse/WFLY-12654?page=com.atlassian.jira.plugi... ] Jim Ma commented on WFLY-12654: ------------------------------- [~parsharma] I haven't started to work on this. If you want to take this, please go ahead. Thanks. > Switch from javax.jws:jsr181-api to jakarta.jws:jakarta.jws-api > --------------------------------------------------------------- > > Key: WFLY-12654 > URL: https://issues.redhat.com/browse/WFLY-12654 > Project: WildFly > Issue Type: Task > Components: Web Services > Reporter: Scott Marlow > Assignee: Jim Ma > Priority: Major > Fix For: 20.0.0.Beta1 > > > Update WildFly to use jakarta.jws:jakarta.jws-api from https://github.com/eclipse-ee4j/jws-api, note that version 2.1 is not yet available as mentioned on [https://github.com/eclipse-ee4j/jws-api/issues/48]. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1124) Automate filters by 2 names

by Hayk Hovsepyan (Jira)

Hayk Hovsepyan created SWSQE-1124: ------------------------------------- Summary: Automate filters by 2 names Key: SWSQE-1124 URL: https://issues.redhat.com/browse/SWSQE-1124 Project: Kiali QE Issue Type: QE Task Reporter: Hayk Hovsepyan Assignee: Hayk Hovsepyan https://issues.redhat.com/browse/OSSM-93 https://polarion.engineering.redhat.com/polarion/#/project/SwiftSunshine/... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2020