[JBoss JIRA] (WFLY-13730) WFLY-9440 fix breaks Galleon provisioning
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-13730?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFLY-13730:
-----------------------------------------
TBH [~brian.stansberry] I think with the changes I have coming in we can remove the dependency on the JACC service from the application-security-domain service and instead use the boolan as an indicator JACC is required - maybe log a warning if not available and requested.
The long term plan is to get rid of these application-security-domain-resources entirely.
> WFLY-9440 fix breaks Galleon provisioning
> -----------------------------------------
>
> Key: WFLY-13730
> URL: https://issues.redhat.com/browse/WFLY-13730
> Project: WildFly
> Issue Type: Bug
> Components: Build System, EJB
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Major
>
> The WFLY-9440 fix breaks server provisioning in my EE9 branch. This is because the feature-spec Galleon generates for the resource doesn't comprehend that the value of the 'enable-jacc' attribute is not relevant to the required capability so it expects to find a 'org.wildfly.security.jacc-policy.false' capability.
> I'm not sure why it doesn't break things elsewhere.
> There are a few possible ways to deal with this:
> 1) Don't register BooleanCapabilityReferenceRecorder with the ENABLE_JACC AttributeDefinition; instead manually do its work in the add/remove/write-attribute handlers. This essentially hides the capability relationship from Galleon by removing it from the resource description metadata and seems to work.
> 2) Have BooleanCapabilityReferenceRecorder correctly implement getRequirementPatternSegments to return an empty array. Perhaps this alone would fix it, but I doubt it.
> 3) Combine #2 with a change of some sort in WildFly Core's ReadFeatureDescriptionHandler to better understand and deal with this particular pattern.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFLY-12815) Wildfly 13 - Thread local state corrupted by deployed application explosion during session timeout leading to WELD-001304 - More than one context active for scope type javax.enterprise.context.SessionScoped
by Matěj Novotný (Jira)
[ https://issues.redhat.com/browse/WFLY-12815?page=com.atlassian.jira.plugi... ]
Matěj Novotný commented on WFLY-12815:
--------------------------------------
Thanks for confirmation.
As for the logging - it is {{DEBUG}} level message, so you'd need to configure your WFLY logging subsystem to spit of debug level logging for Weld.
> Wildfly 13 - Thread local state corrupted by deployed application explosion during session timeout leading to WELD-001304 - More than one context active for scope type javax.enterprise.context.SessionScoped
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-12815
> URL: https://issues.redhat.com/browse/WFLY-12815
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 13.0.0.Final
> Environment: Environment independent the issue, it is purely a logical problem
> Reporter: NUNO GODINHO DE MATOS
> Assignee: Matěj Novotný
> Priority: Major
> Attachments: 01_snippets_of_code_of_sample_app.7z, 02_issue_fix2_using_weld-web-3.1.5-SNAPSHOT.jar.txt.7z, 02_reproducing_issue_on_wildfly20_before_patching_weld_core_web.7z, Sample_App_To_reproduceBug_001_RollingFileAppender.7z, sourceCodeToSendToWildfly.7z
>
>
> The full description of the problem can be seen in stack overflow.
> Please consulder the issue:
> https://stackoverflow.com/questions/58930939/wildflt-13-weld-001304-more-...
> SUMMARY:
> (1) Setup you wildfly to have a session timeout of 1 minute - so that you can esaily make your http sessions timeout
> (2) Program in your WAR application a sessionDestroyed listener that will be broken.
> In our case whenever the session is timing out, we have some code that explodes in wildfly and not in weblogic because it expected for the RequestScope context to be active, but apparently in wildfly when Undertow to start killing of a session the request scope context is not made active so that caused our session destroyed handling to break
> (3) Do this sufficient amount of times to corrupted as may threads in the thread pool as possible
> (4) Now try to interact with your application making use of some session scoped beans .
> If you travel to ay sort of view that makes use of a session scoped bean that thread will be broken with the exception that multiple session scope context implementation are active.
> But this exception will only come out and aply if the thread handling the HTTP request is one of the threads that in the past were used by undertow to handle the session timeout.
> The only threads that have been corrupted forever are those that had a broken sessin timeout
> Explanation for the issue:
> - When the session timeout is being orchestrated by underdow, wildfly is activating a special HttpSessionDescrutionContext and making it active.
> This ACTIVE TRUE/FALSE flag is a ThreadLocal variable.
> So the activation of the scope context is marked on the thread itself.
> - When the thread blows up the thread context will remain for as long at the thread lives
> - in a future request the flag had that thread local variable active already.
> So when the BeanManagaerImpl is hunting to the one and only active http session context it finds the traditional happy path http session context active plust the DestructionSession context that was activated in a previous call.
> All of the illustrative stack traces that facilitate the comprehention of the issue are shown in the stack overflow thread.
> I am of the oppinion that errors like this can happen in the deployed applications.
> It would not hurt if wildfly would somehow be able to ensure that the thread that hand an explosion in a previous request is not corrupted when it is used to handle new requests.
> Many thanks for having a look.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (DROOLS-4605) DMN alpha network
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-4605?page=com.atlassian.jira.plug... ]
Luca Molteni reassigned DROOLS-4605:
------------------------------------
Assignee: Luca Molteni (was: Matteo Mortari)
> DMN alpha network
> -----------------
>
> Key: DROOLS-4605
> URL: https://issues.redhat.com/browse/DROOLS-4605
> Project: Drools
> Issue Type: Epic
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Luca Molteni
> Priority: Major
>
> *Motivation*: a DMN decision table can be evaluated faster than naive algorithm by translating it into a Rete/Phreak, but the current kie7 approach is suffering from performance bottleneck artificially induced by use of kie7 rule units, which provide more harm than benefit to perfomance (performance is actually worst for most "realistic" cases).
> *Goals*: a POC to understand what’s need to be done to support the alpha network compiler (wihout kie7 rule units) in DMN. We currently estimate it will take us 1 to 2 summer sprints and the output will be more epics to implement this feature.
> *Impact*: alpha network compiler code refactors for the better use of.
> One part of the POC was to hard-code the alpha network for a specific table ([DROOLS-4566]) the remained of the poc is to generalize the approach further to fully assess the impacts thanks to the poc.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFLY-13730) WFLY-9440 fix breaks Galleon provisioning
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-13730:
---------------------------------------
Summary: WFLY-9440 fix breaks Galleon provisioning
Key: WFLY-13730
URL: https://issues.redhat.com/browse/WFLY-13730
Project: WildFly
Issue Type: Bug
Components: Build System, EJB
Reporter: Brian Stansberry
Assignee: Brian Stansberry
The WFLY-9440 fix breaks server provisioning in my EE9 branch. This is because the feature-spec Galleon generates for the resource doesn't comprehend that the value of the 'enable-jacc' attribute is not relevant to the required capability so it expects to find a 'org.wildfly.security.jacc-policy.false' capability.
I'm not sure why it doesn't break things elsewhere.
There are a few possible ways to deal with this:
1) Don't register BooleanCapabilityReferenceRecorder with the ENABLE_JACC AttributeDefinition; instead manually do its work in the add/remove/write-attribute handlers. This essentially hides the capability relationship from Galleon by removing it from the resource description metadata and seems to work.
2) Have BooleanCapabilityReferenceRecorder correctly implement getRequirementPatternSegments to return an empty array. Perhaps this alone would fix it, but I doubt it.
3) Combine #2 with a change of some sort in WildFly Core's ReadFeatureDescriptionHandler to better understand and deal with this particular pattern.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (DROOLS-2638) Enumerations drop quotes when double quotes are used
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-2638?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-2638:
--------------------------------
Labels: drools-tools (was: )
> Enumerations drop quotes when double quotes are used
> ----------------------------------------------------
>
> Key: DROOLS-2638
> URL: https://issues.redhat.com/browse/DROOLS-2638
> Project: Drools
> Issue Type: Bug
> Components: Enumerations Editor
> Affects Versions: 7.42.0.Final
> Reporter: Toni Rikkola
> Assignee: Toni Rikkola
> Priority: Major
> Labels: drools-tools
>
> https://github.com/kiegroup/kie-wb-common/pull/1890
> @Rikkola The issue reported in the JIRA seem to be resolved; however I noticed (given an enumeration defined as Person.name: ['a', '"b, c"', 'd']) that the generated DRL is Person( name == "b, c" ) whereas should it be Person( name == "\"b, c\"" )? Closing and re-opening the decision table keeps the correct values selected in the table. I also tried defining the BRL fragment to use a literal value for the enumeration and this gave the same results (DRL possibly incorrect, but re-opening and editing the column was OK).
> I also checked Guided Rules and the DRL is equally wrong however re-opening the rule also led to the wrong enumeration value being selected in the editor (it selected the first option by default) and the DRL showing the same (i.e. I set it to "b, c" and re-opening the file selected a).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months