[JBoss JIRA] (JGRP-2196) TP: internal thread pool is not shut down
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2196?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2196:
---------------------------
Description:
In {{TP.destroy()}}, the regular thread pool and timer are shut down, but not the internal thread pool. The result is that sometimes closing a channel takes a longer time (the max idle time for a thread in the pool). This only happens when an internal thread is active at the time of shut down.
Also use a separate thread factory for internal threads, so we can see by the naming whether a thread is regular or internal, e.g. "jgroups-23" (regular) versus "jgroups-int-33"
was:
In {{TP.destroy()}}, the regular thread pool and timer are shut down, but not the intrnal thread pool.
Also use a separate thread factory for internal threads, so we can see by the naming whether a thread is regular or internal, e.g. "jgroups-23" (regular) versus "jgroups-int-33"
> TP: internal thread pool is not shut down
> -----------------------------------------
>
> Key: JGRP-2196
> URL: https://issues.jboss.org/browse/JGRP-2196
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.4
>
>
> In {{TP.destroy()}}, the regular thread pool and timer are shut down, but not the internal thread pool. The result is that sometimes closing a channel takes a longer time (the max idle time for a thread in the pool). This only happens when an internal thread is active at the time of shut down.
> Also use a separate thread factory for internal threads, so we can see by the naming whether a thread is regular or internal, e.g. "jgroups-23" (regular) versus "jgroups-int-33"
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ELY-1258) ElytronAuthenticator.getPasswordAuthentication() cannot obtain PasswordFactory for Elytron algorithms
by Ondrej Lukas (JIRA)
Ondrej Lukas created ELY-1258:
---------------------------------
Summary: ElytronAuthenticator.getPasswordAuthentication() cannot obtain PasswordFactory for Elytron algorithms
Key: ELY-1258
URL: https://issues.jboss.org/browse/ELY-1258
Project: WildFly Elytron
Issue Type: Bug
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
Priority: Blocker
{{ElytronAuthenticator.getPasswordAuthentication()}} cannot obtain PasswordFactory for Elytron related algorithms. It is caused by missing WildFlyElytronProvider (since {{Security::getProviders}} is used for obtaining providers) for {{PasswordFactory.getInstance}} in [1].
It results to hidden NoSuchAlgorithmException with message _ELY08028: Invalid algorithm "clear"_ and stacktrace:
{code}
org.wildfly.security.password.PasswordFactory.getInstance(PasswordFactory.java:121)
org.wildfly.security.password.PasswordFactory.getInstance(PasswordFactory.java:75)
org.wildfly.security.auth.util.ElytronAuthenticator.getPasswordAuthentication(ElytronAuthenticator.java:92)
java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317)
...
{code}
It causes that even if element {{net-authenticator}} from Elytron client configuration file correctly sets ElytronAuthenticator as default Authenticator, it is not able to work with Elytron related algorithms which means it breaks feature from RFE7-567 - Client Side Security (Elytron Client) => we request blocker flag.
[1] https://github.com/wildfly-security/wildfly-elytron/blob/4df6f4726b7cf070...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ELY-1258) ElytronAuthenticator.getPasswordAuthentication() cannot obtain PasswordFactory for Elytron algorithms
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/ELY-1258?page=com.atlassian.jira.plugin.s... ]
Ondrej Lukas updated ELY-1258:
------------------------------
Affects Version/s: 1.1.0.Beta52
> ElytronAuthenticator.getPasswordAuthentication() cannot obtain PasswordFactory for Elytron algorithms
> -----------------------------------------------------------------------------------------------------
>
> Key: ELY-1258
> URL: https://issues.jboss.org/browse/ELY-1258
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta52
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> {{ElytronAuthenticator.getPasswordAuthentication()}} cannot obtain PasswordFactory for Elytron related algorithms. It is caused by missing WildFlyElytronProvider (since {{Security::getProviders}} is used for obtaining providers) for {{PasswordFactory.getInstance}} in [1].
> It results to hidden NoSuchAlgorithmException with message _ELY08028: Invalid algorithm "clear"_ and stacktrace:
> {code}
> org.wildfly.security.password.PasswordFactory.getInstance(PasswordFactory.java:121)
> org.wildfly.security.password.PasswordFactory.getInstance(PasswordFactory.java:75)
> org.wildfly.security.auth.util.ElytronAuthenticator.getPasswordAuthentication(ElytronAuthenticator.java:92)
> java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317)
> ...
> {code}
> It causes that even if element {{net-authenticator}} from Elytron client configuration file correctly sets ElytronAuthenticator as default Authenticator, it is not able to work with Elytron related algorithms which means it breaks feature from RFE7-567 - Client Side Security (Elytron Client) => we request blocker flag.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/4df6f4726b7cf070...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (JGRP-2196) TP: internal thread pool is not shut down
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2196?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2196:
---------------------------
Description:
In {{TP.destroy()}}, the regular thread pool and timer are shut down, but not the intrnal thread pool.
Also use a separate thread factory for internal threads, so we can see by the naming whether a thread is regular or internal, e.g. "jgroups-23" (regular) versus "jgroups-int-33"
was:In {{TP.destroy()}}, the regular thread pool and timer are shut down, but not the intrnal thread pool.
> TP: internal thread pool is not shut down
> -----------------------------------------
>
> Key: JGRP-2196
> URL: https://issues.jboss.org/browse/JGRP-2196
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.4
>
>
> In {{TP.destroy()}}, the regular thread pool and timer are shut down, but not the intrnal thread pool.
> Also use a separate thread factory for internal threads, so we can see by the naming whether a thread is regular or internal, e.g. "jgroups-23" (regular) versus "jgroups-int-33"
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (DROOLS-1624) Map Handling with Property Reactive Always Enabled
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1624?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-1624:
--------------------------------
Sprint: 2017 Week 24-25
> Map Handling with Property Reactive Always Enabled
> --------------------------------------------------
>
> Key: DROOLS-1624
> URL: https://issues.jboss.org/browse/DROOLS-1624
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.0.0.Final
> Environment: * JDK8
> * Docker running Alpine
> Reporter: KimJohn Quinn
> Assignee: Mario Fusco
> Priority: Minor
>
> Referencing a conversation on [Google Groups - Drools Usage|https://groups.google.com/forum/?fromgroups#!topic/drools-usage/G7r...] and as requested by Mario Fusco...
> We currently have a ruleset that relies heavily on Map facts. In Drools 6.5 we fire approximately 400 rules.
> In Drools 7.0 we get only about 50 rules unless we add the "<property key="drools.propertySpecific" value="ALLOWED"/>" to the kmodule.xml, in which case we fire the full 400 rules or by using @Watch(*) or @Watch(!*) on the rules. It "seems" like only the first evaluations of the rules are firing and then no others after that.
> Our flow generally follows something like below, within a stateful session, using rules only. We fire all rules per-request then close the session.
> Watch for changes to the Map properties
> If a certain property or properties exist a 'populate' rule fires (calls modify())
> The populate rule enriches the map fact. (calls modify())
> Based on #3, more rules fire when certain properties exist (calls modify())
> We are work heavily with rules that depend on loaded available facts up-front and computed properties throughout evaluation.
> I have a couple of usage questions regarding Drools 7, the default enabling of Property Reactive and using Maps as the facts:
> In general, how do maps work with property reactive and respond to modify/insert events? Does Drools look at the Map as a whole, any change re-evaluates the tree, or each individual property within the map re-evaluates the change?
> In Drools 7, by defaulting the property reactive setting, does that mean all rules need to be annotated or they should they work as is (dao or map-based facts) when using modify/insert?
> For reference, we are relying on this doco https://docs.jboss.org/drools/release/7.0.0.Final/drools-docs/html_single....
> I am looking into details or an example how to properly use Maps in Drools 7 with Property Reactive features always enabled (as suggested per the doco)....
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years