April 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AG-138) Rework how recovery connections are created in the ConnectionFactory

by Luis Barreiro (Jira)

Luis Barreiro created AG-138: -------------------------------- Summary: Rework how recovery connections are created in the ConnectionFactory Key: AG-138 URL: https://issues.redhat.com/browse/AG-138 Project: Agroal Issue Type: Bug Components: pool Affects Versions: 1.7 Reporter: Luis Barreiro Assignee: Luis Barreiro Fix For: 1.8 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AG-135) Connection doesn't release.

by Luis Barreiro (Jira)

[ https://issues.redhat.com/browse/AG-135?page=com.atlassian.jira.plugin.sy... ] Luis Barreiro resolved AG-135. ------------------------------ Fix Version/s: 1.8 Resolution: Done This issue let to several discussions with the Narayana team on the best way to fix it, given the circumstances. One a more positive note, the integration is reinforced because we straightened out some details that were not clear. Sorry for how long this took. > Connection doesn't release. > --------------------------- > > Key: AG-135 > URL: https://issues.redhat.com/browse/AG-135 > Project: Agroal > Issue Type: Bug > Components: narayana > Affects Versions: 1.7 > Reporter: bingo chen > Assignee: Luis Barreiro > Priority: Major > Fix For: 1.8 > > > We use narayana as our application JTA component. Through some tests we found an issue that database connection which related to recovery doesn't release. > The narayana use periodic recovery works; During each recovery job execution, the XADataSource is re-established, the connection obtained from the XADataSource doesn't release after recovery job finished, the connections are released only after the GC is executed. > Is this a problem or am I misconfiguring some settings? > the narayana version is 5.10.1.final -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12134) Add org.infinispan:infinispan-multimap, org.infinispan:infinispan-clustered-counter, org.infinispan:infinispan-clustered-lock modules

by Jonathan Putney (Jira)

[ https://issues.redhat.com/browse/WFLY-12134?page=com.atlassian.jira.plugi... ] Jonathan Putney commented on WFLY-12134: ---------------------------------------- Hi Sergey, thanks for your response! Would you happen to be able to point me in the direction of a LockService example that would work with Wildfly 19? Everything I can find seems to be pretty out of date. > Add org.infinispan:infinispan-multimap, org.infinispan:infinispan-clustered-counter, org.infinispan:infinispan-clustered-lock modules > ------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-12134 > URL: https://issues.redhat.com/browse/WFLY-12134 > Project: WildFly > Issue Type: Enhancement > Components: Clustering > Affects Versions: 17.0.0.Beta1 > Reporter: Sergey Aganin > Assignee: Paul Ferraro > Priority: Major > > Please add the modules such that users can use the new features of Infinispan. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13379) Redirect after "j_security_check" login does not work if URL has no trailing slash

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13379?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFLY-13379: ----------------------------------------- Possible workarounds: {code} /subsystem=undertow/configuration=filter/rewrite=test-rewrite-slash:add(redirect="true",target="%U/") /subsystem=undertow/server=default-server/host=default-host/filter-ref=test-rewrite-slash:add(predicate="equals(%R,/context)") {code} or {code} /subsystem=undertow/configuration=filter/expression-filter=app-slash:add(expression="redirect('%U/')") /subsystem=undertow/server=default-server/host=default-host/filter-ref=app-slash:add(predicate="method(GET) and regex(pattern=/context, value=%U, full-match=true)") {code} > Redirect after "j_security_check" login does not work if URL has no trailing slash > ---------------------------------------------------------------------------------- > > Key: WFLY-13379 > URL: https://issues.redhat.com/browse/WFLY-13379 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 19.0.0.Final > Reporter: Wolfgang Knauf > Assignee: Darran Lofthouse > Priority: Major > Attachments: Security.ear, configure.cli, restore-configuration.cli > > > Attached file "Security.ear" contains a web application with a single jsp page "index.jsp" and form based login, which is secured by a Database Identity Store (Elytron). > When calling the root URL of the webapp without specifiying any page and {color:red}*no*{color} trailing slash (http://localhost:8080/SecurityWeb), on WildFly 11 the login form is shown, and then the welcome file "index.jsp" is shown. > On WildFly 19, the login form is shown, and after successful login, there is an error message "404 - Not Found", and the URL in the adress bar changes to http://localhost:8080/j_security_check > It works if the URL is "http://localhost:8080/SecurityWeb/" (trailing slash). It seems WildFly 11 appends the "/" automatically when redirecting to the login form, while WildFly 19 keeps this URL. > To run the sample, you have to add the Elytron config - the script "configure.cli" can be used for this: > jboss-cli.bat --file=path_to\configure.cli > The script "restore-configuration.cli" undoes this configuration. > Username/Password are e.g. "admin"/"admin" - the sample creates a user table based on an ejb and "import.sql" inserts users. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12134) Add org.infinispan:infinispan-multimap, org.infinispan:infinispan-clustered-counter, org.infinispan:infinispan-clustered-lock modules

by Sergey Aganin (Jira)

[ https://issues.redhat.com/browse/WFLY-12134?page=com.atlassian.jira.plugi... ] Sergey Aganin commented on WFLY-12134: -------------------------------------- As a workaround you can use JGroups LockService instead of that module. > Add org.infinispan:infinispan-multimap, org.infinispan:infinispan-clustered-counter, org.infinispan:infinispan-clustered-lock modules > ------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-12134 > URL: https://issues.redhat.com/browse/WFLY-12134 > Project: WildFly > Issue Type: Enhancement > Components: Clustering > Affects Versions: 17.0.0.Beta1 > Reporter: Sergey Aganin > Assignee: Paul Ferraro > Priority: Major > > Please add the modules such that users can use the new features of Infinispan. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2472) TCPConnection allocates 1.5G after reading incorrect header in the connection

by Pavel Molchanov (Jira)

Pavel Molchanov created JGRP-2472: ------------------------------------- Summary: TCPConnection allocates 1.5G after reading incorrect header in the connection Key: JGRP-2472 URL: https://issues.redhat.com/browse/JGRP-2472 Project: JGroups Issue Type: Bug Affects Versions: 3.6.13 Reporter: Pavel Molchanov Assignee: Bela Ban Attachments: 2020-04-21_12h58_50.png, 2020-04-21_15h38_37.png We are using FILE_PING JGroups functionality with Artemis servers. Periodically (very rate) we see that TCPConnection allocates 1650814049 bytes in the receiving buffer. This is similar to the https://issues.redhat.com/browse/JGRP-1117 issue. This issue is happening periodically and it's clearly visible in the memory dumps from Artemis servers. Screen-shots of the dumps are attached. Can TCPConnection be protected from the incorrect input? https://github.com/belaban/JGroups/blob/JGroups-3.6.13.Final/src/org/jgro... Something like this: {code} int len=in.readInt(); if(len==1650814049) throw InvalidStateException(); {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2472) TCPConnection allocates 1.5G after reading incorrect header in the connection

by Pavel Molchanov (Jira)

[ https://issues.redhat.com/browse/JGRP-2472?page=com.atlassian.jira.plugin... ] Pavel Molchanov updated JGRP-2472: ---------------------------------- Attachment: 2020-04-21_12h58_50.png 2020-04-21_15h38_37.png > TCPConnection allocates 1.5G after reading incorrect header in the connection > ----------------------------------------------------------------------------- > > Key: JGRP-2472 > URL: https://issues.redhat.com/browse/JGRP-2472 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.13 > Reporter: Pavel Molchanov > Assignee: Bela Ban > Priority: Major > Attachments: 2020-04-21_12h58_50.png, 2020-04-21_15h38_37.png > > > We are using FILE_PING JGroups functionality with Artemis servers. > Periodically (very rate) we see that TCPConnection allocates 1650814049 bytes in the receiving buffer. > This is similar to the https://issues.redhat.com/browse/JGRP-1117 issue. > This issue is happening periodically and it's clearly visible in the memory dumps from Artemis servers. > Screen-shots of the dumps are attached. > Can TCPConnection be protected from the incorrect input? > https://github.com/belaban/JGroups/blob/JGroups-3.6.13.Final/src/org/jgro... > Something like this: > {code} > int len=in.readInt(); > if(len==1650814049) throw InvalidStateException(); > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12134) Add org.infinispan:infinispan-multimap, org.infinispan:infinispan-clustered-counter, org.infinispan:infinispan-clustered-lock modules

by Jonathan Putney (Jira)

[ https://issues.redhat.com/browse/WFLY-12134?page=com.atlassian.jira.plugi... ] Jonathan Putney commented on WFLY-12134: ---------------------------------------- What would be the proper way to add these modules currently? I'm trying to use infinispan-clustered-lock right now, and it's running into issues with trying to deploy as part of the application rather than being loaded as a module. > Add org.infinispan:infinispan-multimap, org.infinispan:infinispan-clustered-counter, org.infinispan:infinispan-clustered-lock modules > ------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-12134 > URL: https://issues.redhat.com/browse/WFLY-12134 > Project: WildFly > Issue Type: Enhancement > Components: Clustering > Affects Versions: 17.0.0.Beta1 > Reporter: Sergey Aganin > Assignee: Paul Ferraro > Priority: Major > > Please add the modules such that users can use the new features of Infinispan. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4941) Optimize MMR logic within DiscardAttributeChecker.DEFAULT_VALUE

by Paul Ferraro (Jira)

Paul Ferraro created WFCORE-4941: ------------------------------------ Summary: Optimize MMR logic within DiscardAttributeChecker.DEFAULT_VALUE Key: WFCORE-4941 URL: https://issues.redhat.com/browse/WFCORE-4941 Project: WildFly Core Issue Type: Task Components: Management Affects Versions: 12.0.0.Beta1 Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 12.0.0.Beta2 See: https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j... https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j... Basically, in order to deal with the possibility of override registrations, calls to an MRR typically result in it internally working up to the root of the MRR tree and then walking back down to the target address. So this: {code:java} ImmutableManagementResourceRegistration registration = context.getResourceRegistrationFromRoot(address); AttributeDefinition definition = registration.getAttributeAccess(PathAddress.EMPTY_ADDRESS, attributeName).getAttributeDefinition(); {code} is less efficient than: {code:java} ImmutableManagementResourceRegistration registration = context.getResourceRegistrationFromRoot(PathAddress.EMPTY_ADDRESS); AttributeDefinition definition = registration.getAttributeAccess(address, attributeName).getAttributeDefinition(); {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4918) Optimize MMR logic within AttributeConverter.DEFAULT_VALUE

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFCORE-4918?page=com.atlassian.jira.plug... ] Paul Ferraro updated WFCORE-4918: --------------------------------- Summary: Optimize MMR logic within AttributeConverter.DEFAULT_VALUE (was: Optimize MMR logic within DiscardAttributeChecker.DEFAULT_VALUE) > Optimize MMR logic within AttributeConverter.DEFAULT_VALUE > ---------------------------------------------------------- > > Key: WFCORE-4918 > URL: https://issues.redhat.com/browse/WFCORE-4918 > Project: WildFly Core > Issue Type: Task > Components: Management > Affects Versions: 12.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > Fix For: 12.0.0.Beta2 > > > See: > https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j... > https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j... > Basically, in order to deal with the possibility of override registrations, calls to an MRR typically result in it internally working up to the root of the MRR tree and then walking back down to the target address. So this: > {code:java} > ImmutableManagementResourceRegistration registration = context.getResourceRegistrationFromRoot(address); > AttributeDefinition definition = registration.getAttributeAccess(PathAddress.EMPTY_ADDRESS, attributeName).getAttributeDefinition(); > {code} > is less efficient than: > {code:java} > ImmutableManagementResourceRegistration registration = context.getResourceRegistrationFromRoot(PathAddress.EMPTY_ADDRESS); > AttributeDefinition definition = registration.getAttributeAccess(address, attributeName).getAttributeDefinition(); > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 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 April 2020