June 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2086) Intermittent failure in OperationCancellationTestCase

by Yeray Borges Santana (Jira)

[ https://issues.redhat.com/browse/WFCORE-2086?page=com.atlassian.jira.plug... ] Yeray Borges Santana reassigned WFCORE-2086: -------------------------------------------- Assignee: Yeray Borges Santana > Intermittent failure in OperationCancellationTestCase > ----------------------------------------------------- > > Key: WFCORE-2086 > URL: https://issues.redhat.com/browse/WFCORE-2086 > Project: WildFly Core > Issue Type: Bug > Components: Management > Affects Versions: 5.0.0.Beta5 > Reporter: Brian Stansberry > Assignee: Yeray Borges Santana > Priority: Major > > Investigate this: > https://ci.wildfly.org/viewLog.html?buildId=36108&buildTypeId=WildFlyCore... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13559) Header response has changed and missing fields

by Luis Cabral (Jira)

[ https://issues.redhat.com/browse/WFLY-13559?page=com.atlassian.jira.plugi... ] Luis Cabral edited comment on WFLY-13559 at 6/15/20 4:17 AM: ------------------------------------------------------------- Can confirm that this issue happens when using a {{@RequestContext}} bean and {{JAX-RS}} filters, causing the filters to be ignored entirely. Not having a {{@RequestContext}} bean, the filters are picked up correctly. This is happening both on WildFly 19 and 20, but works correctly on 18. So, [~brian.stansberry], imho, not a question, but a valid bug... was (Author: blaghed): Can confirm that this issue happens when using a {{@RequestContext}} bean and {{JAX-RS}} filters, causing the filters to be ignored entirely. Not having a {{@RequestContext}} bean, the filters are picked up correctly. This is happening both on WildFly 19 and 20, but works correctly on 18. So, imho, not a question, but a valid bug... > Header response has changed and missing fields > ---------------------------------------------- > > Key: WFLY-13559 > URL: https://issues.redhat.com/browse/WFLY-13559 > Project: WildFly > Issue Type: Bug > Affects Versions: 19.1.0.Final > Reporter: Alexandru Ciouca > Priority: Major > Attachments: standalone_18.0.0.final.xml, standalone_19.1.0.final.xml > > > I have an application running in WildFly with some open endpoints to call and I tried an upgrade to WildFly 19.1.0.final from 18.0.0.final, but I noticed that something changed when calling the endpoints. In the Response Header I see that some of the fields are changed or are missing. Is this supposed to happen or do I need to add some extra configuration with WildFly 19? > Response WildFly 18.0.0.final: > {code} > HTTP/2 500 > cache-control: no-store, no-cache, must-revalidate > set-cookie: JSESSIONID=pLpPEvZZVekh0Bkqq06muz_cJ4_fmwxsqrt0HUdP.myservices-container-6f5b87f79d-ngzhf; path=/myservices > access-control-allow-headers: origin, content-type, accept, X-XSRF-TOKEN > content-type: application/json > content-length: 182 > link: <http://test.com/afs/rest>; rel="profile" > date: Thu, 04 Jun 2020 07:34:10 GMT > set-cookie: 7951a12696148c7a83e36db56eeb5f91=5ede0885e2c831c4946125e91d3facba; path=/; HttpOnly; Secure > strict-transport-security: max-age=31536000; includeSubdomains > x-xss-protection: 1; mode=block > x-content-type-options: nosniff > x-frame-options: SAMEORIGIN > {code} > Response WildFly 19.1.0.final: > {code} > HTTP/2 200 > set-cookie: JSESSIONID=9siDVU14OoFXojIIVxlMWbxNg1gcuSmLokwamY29.myservices-container-7c8dbf55f5-ctcks; path=/myservices > content-type: application/json > content-length: 182 > date: Thu, 04 Jun 2020 07:27:57 GMT > set-cookie: 7951a12696148c7a83e36db56eeb5f91=3edfc7a7549d107b41669532f6cb594a; path=/; HttpOnly; Secure > cache-control: private > strict-transport-security: max-age=31536000; includeSubdomains > x-xss-protection: 1; mode=block > x-content-type-options: nosniff > x-frame-options: SAMEORIGIN > {code} > As you can see the first thing that changed is the response code, even though the code is the same for both versions. The cache-control is also different and access-control-allow-headers and link fields are missing. > I am attaching also the standalone.xml for both versions. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13559) Header response has changed and missing fields

by Luis Cabral (Jira)

[ https://issues.redhat.com/browse/WFLY-13559?page=com.atlassian.jira.plugi... ] Luis Cabral commented on WFLY-13559: ------------------------------------ Can confirm that this issue happens when using a {{@RequestContext}} bean and {{JAX-RS}} filters, causing the filters to be ignored entirely. Not having a {{@RequestContext}} bean, the filters are picked up correctly. This is happening both on WildFly 19 and 20, but works correctly on 18. So, imho, not a question, but a valid bug... > Header response has changed and missing fields > ---------------------------------------------- > > Key: WFLY-13559 > URL: https://issues.redhat.com/browse/WFLY-13559 > Project: WildFly > Issue Type: Bug > Affects Versions: 19.1.0.Final > Reporter: Alexandru Ciouca > Priority: Major > Attachments: standalone_18.0.0.final.xml, standalone_19.1.0.final.xml > > > I have an application running in WildFly with some open endpoints to call and I tried an upgrade to WildFly 19.1.0.final from 18.0.0.final, but I noticed that something changed when calling the endpoints. In the Response Header I see that some of the fields are changed or are missing. Is this supposed to happen or do I need to add some extra configuration with WildFly 19? > Response WildFly 18.0.0.final: > {code} > HTTP/2 500 > cache-control: no-store, no-cache, must-revalidate > set-cookie: JSESSIONID=pLpPEvZZVekh0Bkqq06muz_cJ4_fmwxsqrt0HUdP.myservices-container-6f5b87f79d-ngzhf; path=/myservices > access-control-allow-headers: origin, content-type, accept, X-XSRF-TOKEN > content-type: application/json > content-length: 182 > link: <http://test.com/afs/rest>; rel="profile" > date: Thu, 04 Jun 2020 07:34:10 GMT > set-cookie: 7951a12696148c7a83e36db56eeb5f91=5ede0885e2c831c4946125e91d3facba; path=/; HttpOnly; Secure > strict-transport-security: max-age=31536000; includeSubdomains > x-xss-protection: 1; mode=block > x-content-type-options: nosniff > x-frame-options: SAMEORIGIN > {code} > Response WildFly 19.1.0.final: > {code} > HTTP/2 200 > set-cookie: JSESSIONID=9siDVU14OoFXojIIVxlMWbxNg1gcuSmLokwamY29.myservices-container-7c8dbf55f5-ctcks; path=/myservices > content-type: application/json > content-length: 182 > date: Thu, 04 Jun 2020 07:27:57 GMT > set-cookie: 7951a12696148c7a83e36db56eeb5f91=3edfc7a7549d107b41669532f6cb594a; path=/; HttpOnly; Secure > cache-control: private > strict-transport-security: max-age=31536000; includeSubdomains > x-xss-protection: 1; mode=block > x-content-type-options: nosniff > x-frame-options: SAMEORIGIN > {code} > As you can see the first thing that changed is the response code, even though the code is the same for both versions. The cache-control is also different and access-control-allow-headers and link fields are missing. > I am attaching also the standalone.xml for both versions. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3766) Improve error message if a parent profile references a child profile's value

by Moulali Shikalwadi (Jira)

[ https://issues.redhat.com/browse/WFCORE-3766?page=com.atlassian.jira.plug... ] Moulali Shikalwadi reassigned WFCORE-3766: ------------------------------------------ Assignee: Moulali Shikalwadi > Improve error message if a parent profile references a child profile's value > ---------------------------------------------------------------------------- > > Key: WFCORE-3766 > URL: https://issues.redhat.com/browse/WFCORE-3766 > Project: WildFly Core > Issue Type: Enhancement > Components: Management > Affects Versions: 3.1.0.Final, 4.0.0.Final, 5.0.0.Alpha3 > Reporter: Brad Maxwell > Assignee: Moulali Shikalwadi > Priority: Major > Labels: domain-mode > Attachments: WFCORE-3766-config.zip > > > EAP 7.1 CP1 boot up fails with the following error message when a profile extension is used > {code:java} > 14:13:39,201 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/profile=temp-full-ha/subsystem=infinispan/cache-container=hibernate/transport=jgroups' are not available: [Host Controller] org.wildfly.clustering.jgroups.default-channel-factory in context 'profile=temp-full-ha'; Possible registration points for this capability: [Host Controller] /profile=*/subsystem=jgroups [Host Controller] > 14:13:39,202 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/profile=temp-full-ha/subsystem=messaging-activemq/server=default/broadcast-group=bg-group1' are not available: [Host Controller] org.wildfly.clustering.jgroups.default-channel-factory in context 'profile=temp-full-ha'; Possible registration points for this capability: [Host Controller] /profile=*/subsystem=jgroups [Host Controller] > 14:13:39,202 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/profile=temp-full-ha/subsystem=infinispan/cache-container=web/transport=jgroups' are not available: [Host Controller] org.wildfly.clustering.jgroups.default-channel-factory in context 'profile=temp-full-ha'; Possible registration points for this capability: [Host Controller] /profile=*/subsystem=jgroups [Host Controller] > 14:13:39,202 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/profile=temp-full-ha/subsystem=messaging-activemq/server=default/discovery-group=dg-group1' are not available: [Host Controller] org.wildfly.clustering.jgroups.default-channel-factory in context 'profile=temp-full-ha'; Possible registration points for this capability: [Host Controller] /profile=*/subsystem=jgroups [Host Controller] > 14:13:39,203 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/profile=temp-full-ha/subsystem=infinispan/cache-container=server/transport=jgroups' are not available: [Host Controller] org.wildfly.clustering.jgroups.default-channel-factory in context 'profile=temp-full-ha'; Possible registration points for this capability: [Host Controller] /profile=*/subsystem=jgroups [Host Controller] > 14:13:39,203 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/profile=temp-full-ha/subsystem=infinispan/cache-container=ejb/transport=jgroups' are not available: [Host Controller] org.wildfly.clustering.jgroups.default-channel-factory in context 'profile=temp-full-ha'; Possible registration points for this capability: [Host Controller] /profile=*/subsystem=jgroups [Host Controller] > 14:13:39,215 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. [Host Controller] > 14:13:39,217 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0178: Aborting with exit code 99 [Host Controller] > 14:13:39,265 INFO [org.jboss.as] (MSC service thread 1-3) WFLYSRV0050: JBoss EAP 7.1.1.GA (WildFly Core 3.0.12.Final-redhat-1) stopped in 26ms [Host Controller] > 14:13:39,611 INFO [org.jboss.as.process.Host Controller.status] (reaper for Host Controller) WFLYPC0011: Process 'Host Controller' finished with an exit status of 99 > 14:13:39,613 INFO [org.jboss.as.process] (Thread-8) WFLYPC0017: Shutting down process controller 14:13:39,613 INFO [org.jboss.as.process] (Thread-8) WFLYPC0016: All processes finished; exiting > {code} > Can this error be improved to better direct the user to the issue? -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1618) missingMessageReceived() never called in NAKACK resulting in memory leak

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-1618?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-1618: -------------------------------- If this occurs with a recent version, then please open a new ticket with configuration and how to reproduce this. > missingMessageReceived() never called in NAKACK resulting in memory leak > ------------------------------------------------------------------------ > > Key: JGRP-1618 > URL: https://issues.redhat.com/browse/JGRP-1618 > Project: JGroups > Issue Type: Bug > Affects Versions: 2.8.1, 2.12.2 > Environment: Java 6 > Reporter: Harry Mark > Assignee: Bela Ban > Priority: Major > Fix For: 3.2.9, 3.3 > > Attachments: 1618-jgrp-patch.jar, NakReceiverWindow.java, screenshot-1.png > > > We are using JGroups 2.8.1 and encountered a memory leak where it eventually ran out of CMS Old Gen memory. The heap dump revealed that the problem was in the xmit_stats ConcurrentHashMap of org.jgroups.protocols.pbcast.NAKACK. > After much analysis here's what we found: when the system is under load, messages can start arriving out of order. When the receiver receives a higher sequence number than expected, it requests the sender retransmit the missing messages with the lower sequence numbers. The sender sends the missing message, however the bug in the NakReceiverWindow meant that the missing message was never purged from the Map that tracks missing messages (xmit_stats) because missingMessageReceived() was never invoked. Over time this Map grows and starts using up CMS Old Gen; the only way it would get reduced was when a server left the cluster and the missing messages were purged for that server. > In JMX, the MissingMsgsReceived attribute of jgroups:cluster=*,protocol=NAKACK,type=protocol was always zero, confirming that it never purged any received "missing messages". > When I looked at the most recent GA version 3.2.8 of NakReceiverWindow.java , it has the corrected logic that ensures that missingMessageReceived() is called. I checked the the most recent 2.x, which is 2.12.2, and found it also has the same bug in the logic as 2.8.1. This bug may apply to other 2.x but I did not check. > Attached is the fixed NakReceiverWindow.java for 2.8.1. > After applying the patch, the memory leak went away. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5095) [DMN Designer] Investigate performance switching between editor instances

by Michael Biarnes Kiefer (Jira)

[ https://issues.redhat.com/browse/DROOLS-5095?page=com.atlassian.jira.plug... ] Michael Biarnes Kiefer updated DROOLS-5095: ------------------------------------------- Fix Version/s: 7.40.0.Final (was: 7.39.0.Final) > [DMN Designer] Investigate performance switching between editor instances > ------------------------------------------------------------------------- > > Key: DROOLS-5095 > URL: https://issues.redhat.com/browse/DROOLS-5095 > Project: Drools > Issue Type: Task > Components: DMN Editor > Affects Versions: 7.33.0.Final > Reporter: Jozef Marko > Assignee: Guilherme Gomes > Priority: Minor > Labels: drools-tools > Fix For: 7.40.0.Final > > Attachments: switch-dmn.webm > > > This JIRA is to investigate the reported performance issue switching between different DMN Designer instances in Business Central. > The issue was noticed by [~jomarko] when testing DROOLS-5058 (although the fix therein should have had *zero* affect on switching). > For more details see the video [^switch-dmn.webm] > h2. Manual acceptance test > - Prepare 5 DMN models in project > - Open all in parallel > - Try to switch between them, keep all opened -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4830) Add a Docker composer to connect BC and Kie Server images

by Michael Biarnes Kiefer (Jira)

[ https://issues.redhat.com/browse/DROOLS-4830?page=com.atlassian.jira.plug... ] Michael Biarnes Kiefer updated DROOLS-4830: ------------------------------------------- Fix Version/s: 7.40.0.Final (was: 7.39.0.Final) > Add a Docker composer to connect BC and Kie Server images > --------------------------------------------------------- > > Key: DROOLS-4830 > URL: https://issues.redhat.com/browse/DROOLS-4830 > Project: Drools > Issue Type: Feature Request > Components: docker images > Affects Versions: 7.30.0.Final > Reporter: Ricardo Zanini Fernandes > Assignee: Ricardo Zanini Fernandes > Priority: Major > Fix For: 7.40.0.Final > > > It's natural to have BC and KIE servers working together. Would be nice to have a Docker composer file that fires up the two instances at once. This will support use cases such authoring on BC and deploying in the connected KIE Server. > References: https://www.drools.org/download/download.html -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3799) Check and fix i18n

by Michael Biarnes Kiefer (Jira)

[ https://issues.redhat.com/browse/DROOLS-3799?page=com.atlassian.jira.plug... ] Michael Biarnes Kiefer updated DROOLS-3799: ------------------------------------------- Fix Version/s: 7.40.0.Final (was: 7.39.0.Final) > Check and fix i18n > ------------------ > > Key: DROOLS-3799 > URL: https://issues.redhat.com/browse/DROOLS-3799 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Reporter: Gabriele Cardosi > Assignee: Yeser Amer > Priority: Major > Labels: ScenarioSimulation, drools-tools > Fix For: 7.40.0.Final > > > Check that i18n works for all widgets (menu, rightpanel, cheatsheet, etc) and eventually fix it. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2254) Automate .proto files rebuild in pom.xml

by Michael Biarnes Kiefer (Jira)

[ https://issues.redhat.com/browse/DROOLS-2254?page=com.atlassian.jira.plug... ] Michael Biarnes Kiefer updated DROOLS-2254: ------------------------------------------- Fix Version/s: 7.40.0.Final (was: 7.39.0.Final) > Automate .proto files rebuild in pom.xml > ---------------------------------------- > > Key: DROOLS-2254 > URL: https://issues.redhat.com/browse/DROOLS-2254 > Project: Drools > Issue Type: Task > Components: tools > Affects Versions: 7.5.0.Final > Reporter: Dmitry Volodin > Assignee: Dmitry Volodin > Priority: Minor > Fix For: 7.40.0.Final > > > According to contribution guide, any .proto file or protobuf version changes it's necessary to download protoc utility and regenerate Java classes based on .proto files. > This will add automation for downloading protoc utility and Java classes generation based on Maven Protocol Buffers Plugin. There is no timestamps and other build related info inside generated Java files and no changes will be added on each new build. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3160) adapt kie upstream reps for Thorntail 2.2 (ex WildFly Swarm)

by Michael Biarnes Kiefer (Jira)

[ https://issues.redhat.com/browse/DROOLS-3160?page=com.atlassian.jira.plug... ] Michael Biarnes Kiefer updated DROOLS-3160: ------------------------------------------- Fix Version/s: 7.40.0.Final (was: 7.39.0.Final) > adapt kie upstream reps for Thorntail 2.2 (ex WildFly Swarm) > ------------------------------------------------------------ > > Key: DROOLS-3160 > URL: https://issues.redhat.com/browse/DROOLS-3160 > Project: Drools > Issue Type: Feature Request > Reporter: Michael Biarnes Kiefer > Assignee: Toni Rikkola > Priority: Major > Fix For: 7.40.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 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 June 2020