March 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3962) onComplete for async listeners not always called

by John Sanda (JIRA)

[ https://issues.jboss.org/browse/WFLY-3962?page=com.atlassian.jira.plugin.... ] John Sanda reopened WFLY-3962: ------------------------------ I am reopening this since we are still seeing this with WildFly 8.2.0.Final. I will see if we can reproduce with 9.0.0.Beta1 early next week. > onComplete for async listeners not always called > ------------------------------------------------ > > Key: WFLY-3962 > URL: https://issues.jboss.org/browse/WFLY-3962 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.0.0.Final, 8.1.0.Final > Reporter: Heiko Rupp > Assignee: Stuart Douglas > Fix For: 8.2.0.Final, 9.0.0.Beta1 > > > I have a servlet filter that does > chain.doFilter(requestWrapper, responseWrapper); > if (request.isAsyncStarted()) { > asyncListener = request.getAsyncContext().createListener(JsonPAsyncListener.class); > request.getAsyncContext().addListener(asyncListener, requestWrapper, responseWrapper); > } > And (sometimes) this works well so that the onComplete() method of the listener is called. > But this does not happen always. In some (repeatable) condition none of the callback methods in my AsyncListener are called. > I was first thinking that the servlet (resteasy) behind chain.doFilter() is so fast that it completes > before I can add the listener. > But then I tried adding a Thread.sleep() in the RE code which did not change anything. > Similar when I do a startAsync() and add the listener before calling chain.doFilter() > This happens both on Wfly 8.0 and 8.1 > Basically it boils down that if the "backend" uses Futures.immediateFuture(result) , onComplete is not called. > I have created a as small as possible war file + a read me on how to drive that via curl. > See https://github.com/pilhuhn/misc/tree/master/web-goo > I just added 2 examples to the readme file that show that if no > wrapping by the filter is requested, the resteasy code works with > both Futures.immediate... and Futures.transform(...) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-1921) Race condition in GroupRequest

by Dennis Reed (JIRA)

[ https://issues.jboss.org/browse/JGRP-1921?page=com.atlassian.jira.plugin.... ] Dennis Reed closed JGRP-1921. ----------------------------- Resolution: Won't Fix Does not affect current versions of JGroups. If a fix is needed for EAP 5.2, contact Red Hat support through the normal channels. > Race condition in GroupRequest > ------------------------------ > > Key: JGRP-1921 > URL: https://issues.jboss.org/browse/JGRP-1921 > Project: JGroups > Issue Type: Bug > Affects Versions: 2.6.23 > Reporter: Dennis Reed > Assignee: Dennis Reed > Priority: Minor > > Race condition in GroupRequest can make it wait for the full timeout even after all responses are received. > GroupRequest.execute broadcasts the request, sets "done=false", then waits for a reply. > If all the replies come in before it sets done=false, it will overwrite the done=true set by the responses and wait for the full timeout, and then return false. > Note that the internal uses by MessageDispatcher/etc do not check the return value from execute, so this does not affect the data returned, only how long the call blocks for. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-1921) Race condition in GroupRequest

by Dennis Reed (JIRA)

[ https://issues.jboss.org/browse/JGRP-1921?page=com.atlassian.jira.plugin.... ] Dennis Reed commented on JGRP-1921: ----------------------------------- Later versions (I checked 3.0.9) are not affected, as they do not set done=false in execute(). > Race condition in GroupRequest > ------------------------------ > > Key: JGRP-1921 > URL: https://issues.jboss.org/browse/JGRP-1921 > Project: JGroups > Issue Type: Bug > Affects Versions: 2.6.23 > Reporter: Dennis Reed > Assignee: Dennis Reed > Priority: Minor > > Race condition in GroupRequest can make it wait for the full timeout even after all responses are received. > GroupRequest.execute broadcasts the request, sets "done=false", then waits for a reply. > If all the replies come in before it sets done=false, it will overwrite the done=true set by the responses and wait for the full timeout, and then return false. > Note that the internal uses by MessageDispatcher/etc do not check the return value from execute, so this does not affect the data returned, only how long the call blocks for. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-1921) Race condition in GroupRequest

by Dennis Reed (JIRA)

Dennis Reed created JGRP-1921: --------------------------------- Summary: Race condition in GroupRequest Key: JGRP-1921 URL: https://issues.jboss.org/browse/JGRP-1921 Project: JGroups Issue Type: Bug Affects Versions: 2.6.23 Reporter: Dennis Reed Assignee: Dennis Reed Priority: Minor Race condition in GroupRequest can make it wait for the full timeout even after all responses are received. GroupRequest.execute broadcasts the request, sets "done=false", then waits for a reply. If all the replies come in before it sets done=false, it will overwrite the done=true set by the responses and wait for the full timeout, and then return false. Note that the internal uses by MessageDispatcher/etc do not check the return value from execute, so this does not affect the data returned, only how long the call blocks for. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-616) Ensure end users cannot set the ""execute-for-coordinator" operation header via the HTTP interface

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-616: --------------------------------------- Summary: Ensure end users cannot set the ""execute-for-coordinator" operation header via the HTTP interface Key: WFCORE-616 URL: https://issues.jboss.org/browse/WFCORE-616 Project: WildFly Core Issue Type: Task Components: Domain Management Affects Versions: 1.0.0.Alpha19 Reporter: Brian Stansberry The "execute-for-coordinator" header is used internally in domain-wide operation execution to indicate that a call is being made on behalf of the DC. End users should not be able to use it. Client calls that go through the native handling (including HTTP upgrade) have any such header stripped by ModelControllerClientOperationHandler.ExecuteRequestHandler. We need to do the same thing in the domain-http code for non-upgrade HTTP calls. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3962) onComplete for async listeners not always called

by John Sanda (JIRA)

[ https://issues.jboss.org/browse/WFLY-3962?page=com.atlassian.jira.plugin.... ] John Sanda commented on WFLY-3962: ---------------------------------- It looks like we are still seeing this in WildFly 8.2.0.Final. Our QE team created https://issues.jboss.org/browse/HWKMETRICS-47 and then I found this issue. It does not happen consistently with every test run, but it is somewhat frequent. > onComplete for async listeners not always called > ------------------------------------------------ > > Key: WFLY-3962 > URL: https://issues.jboss.org/browse/WFLY-3962 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.0.0.Final, 8.1.0.Final > Reporter: Heiko Rupp > Assignee: Stuart Douglas > Fix For: 8.2.0.Final, 9.0.0.Beta1 > > > I have a servlet filter that does > chain.doFilter(requestWrapper, responseWrapper); > if (request.isAsyncStarted()) { > asyncListener = request.getAsyncContext().createListener(JsonPAsyncListener.class); > request.getAsyncContext().addListener(asyncListener, requestWrapper, responseWrapper); > } > And (sometimes) this works well so that the onComplete() method of the listener is called. > But this does not happen always. In some (repeatable) condition none of the callback methods in my AsyncListener are called. > I was first thinking that the servlet (resteasy) behind chain.doFilter() is so fast that it completes > before I can add the listener. > But then I tried adding a Thread.sleep() in the RE code which did not change anything. > Similar when I do a startAsync() and add the listener before calling chain.doFilter() > This happens both on Wfly 8.0 and 8.1 > Basically it boils down that if the "backend" uses Futures.immediateFuture(result) , onComplete is not called. > I have created a as small as possible war file + a read me on how to drive that via curl. > See https://github.com/pilhuhn/misc/tree/master/web-goo > I just added 2 examples to the readme file that show that if no > wrapping by the filter is requested, the resteasy code works with > both Futures.immediate... and Futures.transform(...) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3988) Authorization denied for authenticated users when @PermitAll is used on EJB JAX-WS endpoint

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/WFLY-3988?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated WFLY-3988: ---------------------------------- Fix Version/s: 9.0.0.Beta1 > Authorization denied for authenticated users when @PermitAll is used on EJB JAX-WS endpoint > ------------------------------------------------------------------------------------------- > > Key: WFLY-3988 > URL: https://issues.jboss.org/browse/WFLY-3988 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 8.1.0.Final > Reporter: Kyle Lape > Assignee: Jim Ma > Fix For: 9.0.0.Beta1 > > > Given this endpoint: > {code:java} > @Stateless > @WebService(endpointInterface="com.redhat.gss.SecureEndpoint") > @DeclareRoles({"a","b"}) > @WebContext(contextRoot="/endpoint",urlPattern="/e",authMethod="BASIC") > public class SecureEndpointE implements SecureEndpoint { > @RolesAllowed({"a"}) > public String a() { > return "Success"; > } > @RolesAllowed({"b"}) > public String b() { > return "Success"; > } > @PermitAll > public String c() { > return "Success"; > } > } > {code} > One would expect any authenticated user to be able to invoke {{c()}}, but only users with a role found in {{@DelareRoles}} can invoke it. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-751) Different threads accessing LeftTuple fields that reference LeftTupleSet

by Mark Proctor (JIRA)

[ https://issues.jboss.org/browse/DROOLS-751?page=com.atlassian.jira.plugin... ] Mark Proctor updated DROOLS-751: -------------------------------- Priority: Critical (was: Blocker) > Different threads accessing LeftTuple fields that reference LeftTupleSet > ------------------------------------------------------------------------ > > Key: DROOLS-751 > URL: https://issues.jboss.org/browse/DROOLS-751 > Project: Drools > Issue Type: Bug > Reporter: Tibor Zimányi > Assignee: Mark Proctor > Priority: Critical > > In class LeftTupleSetsImpl there are missing nullchecks in some methods that contains handling LeftTuple instances. I.e. in method removeInsert there is LeftTuple variable previous that is not nullchecked. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-751) Different threads accessing LeftTuple fields that reference LeftTupleSet

by Mark Proctor (JIRA)

[ https://issues.jboss.org/browse/DROOLS-751?page=com.atlassian.jira.plugin... ] Mark Proctor updated DROOLS-751: -------------------------------- Summary: Different threads accessing LeftTuple fields that reference LeftTupleSet (was: Missing nullchecks in LeftTupleSetsImpl) > Different threads accessing LeftTuple fields that reference LeftTupleSet > ------------------------------------------------------------------------ > > Key: DROOLS-751 > URL: https://issues.jboss.org/browse/DROOLS-751 > Project: Drools > Issue Type: Bug > Reporter: Tibor Zimányi > Assignee: Mark Proctor > > In class LeftTupleSetsImpl there are missing nullchecks in some methods that contains handling LeftTuple instances. I.e. in method removeInsert there is LeftTuple variable previous that is not nullchecked. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-751) Different threads accessing LeftTuple fields that reference LeftTupleSet

by Mark Proctor (JIRA)

[ https://issues.jboss.org/browse/DROOLS-751?page=com.atlassian.jira.plugin... ] Mark Proctor updated DROOLS-751: -------------------------------- Priority: Blocker (was: Major) > Different threads accessing LeftTuple fields that reference LeftTupleSet > ------------------------------------------------------------------------ > > Key: DROOLS-751 > URL: https://issues.jboss.org/browse/DROOLS-751 > Project: Drools > Issue Type: Bug > Reporter: Tibor Zimányi > Assignee: Mark Proctor > Priority: Blocker > > In class LeftTupleSetsImpl there are missing nullchecks in some methods that contains handling LeftTuple instances. I.e. in method removeInsert there is LeftTuple variable previous that is not nullchecked. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

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 March 2015