[JBoss JIRA] (WFLY-12344) SecurityManager push/pull is expensive also for datasources
by Stefano Maestri (Jira)
Stefano Maestri created WFLY-12344:
--------------------------------------
Summary: SecurityManager push/pull is expensive also for datasources
Key: WFLY-12344
URL: https://issues.jboss.org/browse/WFLY-12344
Project: WildFly
Issue Type: Enhancement
Components: JCA
Affects Versions: 17.0.1.Final
Reporter: Stefano Maestri
Assignee: Stefano Maestri
Fix For: 18.0.0.Beta1
Pushing SecurityDefinition in securityManager in eery SubjectFactory is creating a lot of object with an impact on performance.
Double checking WFLY-6372 it seems not needed for that issue.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (WFCORE-4589) WFCORE-4507 Upgrade Jackson to 2.9.9.1
by Martin Stefanko (Jira)
Martin Stefanko created WFCORE-4589:
---------------------------------------
Summary: WFCORE-4507 Upgrade Jackson to 2.9.9.1
Key: WFCORE-4589
URL: https://issues.jboss.org/browse/WFCORE-4589
Project: WildFly Core
Issue Type: Component Upgrade
Components: Security
Reporter: Martin Stefanko
Assignee: Darran Lofthouse
Fix For: 9.0.1.Final
Upgrade the Jackson version to 2.9.9 as used for Elytron subsystem testing to match the version in WildFly.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (WFLY-12343) Integrate server probes in MP Health readiness check
by Jeff Mesnil (Jira)
Jeff Mesnil created WFLY-12343:
----------------------------------
Summary: Integrate server probes in MP Health readiness check
Key: WFLY-12343
URL: https://issues.jboss.org/browse/WFLY-12343
Project: WildFly
Issue Type: Feature Request
Components: MP Health
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
MicroProfile Health 2.0 introduced a readiness health check.
WFLY-12228 added support for MicroProfile Health 2.0 without enhancing the readiness health check.
This RFE enhances it with 3 probes (that are part of the EAP readiness probe script at [1]):
* server-status - returns UP when the server-state is READY
* boot-errors - return UP if there are no boot-errors
* deployment-status - returns UP if status for all deployments is OK
[1] https://github.com/jboss-container-images/jboss-eap-modules/blob/251f422c...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (DROOLS-4386) Wrong matched rules set were fired when one of the condition having empty cell in drools 6.5.0 using Jdk 1.8
by Rahul Ramachar (Jira)
Rahul Ramachar created DROOLS-4386:
--------------------------------------
Summary: Wrong matched rules set were fired when one of the condition having empty cell in drools 6.5.0 using Jdk 1.8
Key: DROOLS-4386
URL: https://issues.jboss.org/browse/DROOLS-4386
Project: Drools
Issue Type: Bug
Components: decision tables
Affects Versions: 6.5.0.Final
Environment: Windows, Java 1.8 and drools 6.5.0.Final
Reporter: Rahul Ramachar
Assignee: Mario Fusco
In JDK 1.7 we were using Drools 5.3.0.Final version and we are migrating to jdk 1.8 so drools 5.3.0.Final was not supported in which we were using Package Builder.
We migrated JDK 1.8 with drools 6.5.0.Final which uses Kie API to implement rules
Below is the decision table I am using:
Customer Rule:
Condition Condition Action
---------------------------------------------------
Rule NO. Type Years Discount
---------------------------------------------------
1 "Individual" 5 15
2 "Individual" 3 10
3 "Individual" 20
if I insert customer object as "Type" = Individual and "Years" = 5
after fireAllRules
It fires two rules i.e Rule no. 1 and 3 and gives the 3rd Rule number as result instead of Rule number 1, inturn gives Discount as 20 instead of 15 which is wrong result.
if I insert customer object as "Type" = Individual and "Years" = 3
after fireAllRules
It fires two rules i.e Rule no. 2 and 3 and gives the 3rd rule number as result instead of Rule number 2, inturn gives Discount as 20 instead of 10 which is wrong result.
Exact rule match is not happening and providing wrong results.
Could you please give the solution for this it is breaking so many rules in the application.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (JGRP-2362) Providing logical member name in JDBC_PING
by S Pokutniy (Jira)
[ https://issues.jboss.org/browse/JGRP-2362?page=com.atlassian.jira.plugin.... ]
S Pokutniy commented on JGRP-2362:
----------------------------------
Sure, apologies for unclear description. What happens is this:
1) I can hardly use CREATE Table in parameter initialize_sql in JDBC_PING as it is done in an DML in my case.
2) My servers do crash frequently and can also be killed. If I do not do any clearing of old datasets the new start of the server lasts 3 (GSM.getJoinClusterTimeout) * 10(GSM.MaxJoinAttempts) * number of old entries = i.e. at least 30 seconds * number of old entries for the same server with its old UUID. Parameter remove_all_data_on_view_change does not seem to clear the data only when coordinator changes.
3) Therefore I would like to delete old entries in JDBC_PING's parameter initialize_sql by using delete from JGROUPSPING where coordinator = x or logical_name = x As own_addr is a UUID and is always different it can hardly be used here and the logical address or the channel name would be a gain here but it is not there. In the source code I see that adding it would not be that diffecult as the data is already available in the object PingData.
If it is unclear I would gladly write more details.
> Providing logical member name in JDBC_PING
> ------------------------------------------
>
> Key: JGRP-2362
> URL: https://issues.jboss.org/browse/JGRP-2362
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 4.0.17, 4.0.18, 4.0.19, 4.1.0, 4.0.20
> Reporter: S Pokutniy
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.1.2
>
>
> When using JDBC_PING and logical names instead of UUIDs and one of the cluster member crashes or get killed and this member is not coordinator then its database set still remains in the database as long as coordinator changes (independently from remove_old_coords_on_view_change /remove_all_data_on_view_change). If the the cluster is then restarted the old dataset makes connect() much slower (+30 seconds), as the members seem to be tryting to connect to it. Parameter remove_all_data_on_view_change seems to be the solution but it does not work as long as coordinator does not change, so practically the same as remove_old_coords_on_view_change.
> The only solution seems to be to provide an appropriate delete statement in parameter initialize_sql, which would delete old entry, for example like this: delete from JGROUPSPING where ping_data like '%logical name%'. However, this is neither really quick nor the ideal solution, as ping_data's datatype is bytea or bit varying.
> It would be great to have also logical name in JGROUPSPING, which is instead per default in insert(). This is also easy to implement as there is access to this information in PingData.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months