[JBoss JIRA] (JGRP-2253) FD_SOCK is not working in AWS environment
by Sibin Karnavar (JIRA)
[ https://issues.jboss.org/browse/JGRP-2253?page=com.atlassian.jira.plugin.... ]
Sibin Karnavar edited comment on JGRP-2253 at 5/10/18 10:30 AM:
----------------------------------------------------------------
Looks like I am unable to attach my complete logs. I was getting an error like 'token missing' while uploading my log file.
During Startup:
monitoringInterval: 30000 and queueSizeAlertThreshold: 100
2018-05-02 21:52:16.017 TRACE 1108 --- [jgroups-13,SOM-SKS-stage_SJX_290420181509_XSJ,ip-xx-xx-xx-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-xx-xx-xxx-143-60500: who-has-sock ip-xx-xx-xxx-143-60500
2018-05-02 21:52:16.021 TRACE 1108 --- [jgroups-13,SOM-SKS-stage_SJX_290420181509_XSJ,ip-xx-xx-xxx-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-xx-xx-xxx-143-60500: received SUSPECT message from ip-xx-xx-xxx-48-43121: suspects=[ip-xx-xx-xxx-143-60500]
2018-05-02 21:52:16.022 TRACE 1108 --- [jgroups-13,SOM-SKS-stage_SJX_290420181509_XSJ,ip-xx-xx-xxx-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-xx-xx-xxx-143-60500: received SUSPECT message from ip-xx-xx-xxx-48-43121: suspects=[ip-xx-xx-xxx-163-65450]
2018-05-02 21:52:16.024 TRACE 1108 --- [jgroups-3,SOM-SKS-stage_SJX_290420181509_XSJ,ip-xx-xx-xxx-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-xx-xx-xxx-143-60500: received UNSUSPECT message from ip-xx-xx-xxx-48-43121: mbrs=[ip-xx-xx-xxx-143-60500]
2018-05-02 21:52:16.025 TRACE 1108 --- [jgroups-4,SOM-SKS-stage_SJX_290420181509_XSJ,ip-xx-xx-xxx-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-xx-xx-xxx-143-60500: received UNSUSPECT message from ip-xx-xx-xxx-48-43121: mbrs=[ip-xx-xx-xxx-163-65450]
2018-05-02 21:52:16.030 TRACE 1108 --- [jgroups-17,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-xx-xx-xxx-143-60500: received UNSUSPECT message from ip-xx-xx-xxx-163-65450: mbrs=[ip-xx-xx-xxx-143-60500]
2018-05-02 21:52:16.030 INFO 1108 --- [localhost-startStop-1] c.w.s.c.ServiceClusterCoordinator : - - Detected change in view membership: [ip-10-91-137-163-65450|2] (3) [ip-xx-xx-xxx-163-65450, ip-xx-xx-xxx-48-43121, ip-xx-xx-xxx-143-60500]
2018-05-02 21:52:16.030 INFO 1108 --- [localhost-startStop-1] c.w.s.c.ServiceClusterCoordinator : - - I am not the master!
2018-05-02 21:52:16.031 INFO 1108 --- [localhost-startStop-1] c.w.s.c.ServiceClusterCoordinator : - - ip-xx-xx-xxx-163-65450 is the master for service SOM-SKS
2018-05-02 21:52:16.032 INFO 1108 --- [localhost-startStop-1] c.w.s.c.ServiceClusterCoordinator : - - Successfully connected to clusterName: 'SOM-SKS-stage_SJX_290420181509_XSJ'
2018-05-02 21:52:16.032 TRACE 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-xx-xx-xxx-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: got cache from ip-xx-xx-xxx-163-65450: cache is ip-xx-xx-xxx-143-60500: xx.xx.xxx.143:7804 (0 ms old)
ip-xx-xx-xx-48-43121: xx.xx.xxx.48:7804 (0 ms old)
ip-xx-xx-xxx-163-65450: xx.xx.xxx.163:7804 (0 ms old)
2018-05-02 21:52:16.032 TRACE 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-xx-xx-xxx-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-xx-xx-xxx-143-60500: pinger_thread started
2018-05-02 21:52:16.033 DEBUG 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-xx-xx-xxx-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-xx-xx-xxx-143-60500: pingable_mbrs=[ip-xx-xx-xxx-163-65450, ip-xx-xx-xx-48-43121, ip-xx-xx-xxx-143-60500], ping_dest=ip-xx-xx-xxx-163-65450
2018-05-02 21:52:16.035 TRACE 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-xx-xx-xxx-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-xx-xx-xxx-143-60500: ping_dest=ip-xx-xx-xxx-163-65450, ping_sock=Socket[addr=/xx.xx.xx.163,port=7804,localport=7805], cache=ip-xx-xx-xxx-143-60500: xx.xx.xxx.143:7804 (2 ms old)
ip-xx-xx-xxx-48-43121: xx.xx.xxx.48:7804 (2 ms old)
ip-xx-xx-xxx-163-65450: xx.xx.xx.163:7804 (2 ms old)
{color:red}Below logs are generated after terminating the master node from AWS console. I have terminated the EC2 instance. This logs are printed only post 13 seconds after killing the other node.{color}
2018-05-02 21:54:40.040 TRACE 1108 --- [jgroups-17,SOM-SKS-stage_SJX_290420181509_XSJ,ip-xx-xx-xxx-143-60500] org.jgroups.protocols.VERIFY_SUSPECT : - - verifying that [ip-xx-xx-xxx-163-65450] is dead
2018-05-02 21:54:43.041 TRACE 1108 --- [VERIFY_SUSPECT.TimerThread-19,SOM-SKS-stage_SJX_290420181509_XSJ,ip-xx-xx-xxx-143-60500] org.jgroups.protocols.VERIFY_SUSPECT : - - [ip-xx-xx-xxx-163-65450] is dead (passing up SUSPECT event)
2018-05-02 21:54:43.202 DEBUG 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-xx-xx-xxx-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-xx-xx-xxx-143-60500: socket to ip-xx-xx-xxx-163-65450 was closed gracefully
2018-05-02 21:54:43.203 DEBUG 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-xx-xx-xxx-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-xx-xx-xxx-143-60500: pingable_mbrs=[ip-xx-xx-xxx-48-43121, ip-xx-xx-xxx-143-60500], ping_dest=ip-xx-xx-xxx-48-43121
2018-05-02 21:54:43.203 DEBUG 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-xx-xx-xxx-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-xx-xx-xxx-143-60500: failed connecting to ip-xx-xx-xxx-48-43121: Address already in use (Bind failed)
2018-05-02 21:54:43.203 DEBUG 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-xx-xx-xxx-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-xx-xx-xxx-143-60500: broadcasting suspect(ip-xx-xx-xxx-48-43121)
2018-05-02 21:54:43.203 TRACE 1108 --- [jgroups-20,SOM-SKS-stage_SJX_290420181509_XSJ,ip-xx-xx-xxx-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-xx-xx-xxx-143-60500: received SUSPECT message from ip-xx-xx-xxx-143-60500: suspects=[ip-xx-xx-xxx-48-43121]
2018-05-02 21:54:43.204 DEBUG 1108 --- [jgroups-20,SOM-SKS-stage_SJX_290420181509_XSJ,ip-xx-xx-xxx-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-xx-xx-xxx-143-60500: suspecting [ip-xx-xx-xxx-48-43121]
2018-05-02 21:54:43.204 TRACE 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-xx-xx-xxx-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-xx-xx-xxx-143-60500: pinger thread terminated
2018-05-02 21:54:43.206 TRACE 1108 --- [jgroups-20,SOM-SKS-stage_SJX_290420181509_XSJ,ip-xx-xx-xxx-143-60500] org.jgroups.protocols.VERIFY_SUSPECT : - - verifying that [ip-xx-xx-xxx-48-43121] is dead
2018-05-02 21:54:43.208 TRACE 1108 --- [jgroups-20,SOM-SKS-stage_SJX_290420181509_XSJ,ip-xx-xx-xxx-143-60500] org.jgroups.protocols.VERIFY_SUSPECT : - - member ip-xx-xx-xxx-48-43121 was unsuspected
2018-05-02 21:54:43.208 DEBUG 1108 --- [jgroups-20,SOM-SKS-stage_SJX_290420181509_XSJ,ip-xx-xx-xxx-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-xx-xx-xxx-143-60500: broadcasting unsuspect(ip-xx-xx-xxx-48-43121)
2018-05-02 21:54:43.208 TRACE 1108 --- [jgroups-18,SOM-SKS-stage_SJX_290420181509_XSJ,ip-xx-xx-xxx-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-xx-xx-xxx-143-60500: received UNSUSPECT message from ip-xx-xx-xxx-143-60500: mbrs=[ip-xx-xx-xxx-48-43121]
2018-05-02 21:54:43.208 INFO 1108 --- [jgroups-17,SOM-SKS-stage_SJX_290420181509_XSJ,ip-xx-xx-xxx-143-60500] c.w.s.c.ServiceClusterCoordinator : - - Detected change in view membership: [ip-xx-xx-xxx-48-43121|3] (2) [ip-xx-xx-xxx-48-43121, ip-xx-xx-xxx-143-60500]
2018-05-02 21:54:43.209 INFO 1108 --- [jgroups-17,SOM-SKS-stage_SJX_290420181509_XSJ,ip-xx-xx-xxx-143-60500] c.w.s.c.ServiceClusterCoordinator : - - I am not the master!
2018-05-02 21:54:43.209 INFO 1108 --- [jgroups-17,SOM-SKS-stage_SJX_290420181509_XSJ,ip-xx-xx-xxx-143-60500] c.w.s.c.ServiceClusterCoordinator : - - ip-xx-xx-xxx-48-43121 is the master for service SOM-SKS
was (Author: sibin.karnavar):
Looks like I am unable to attach my complete logs. I was getting an error like 'token missing' while uploading my log file.
During Startup:
monitoringInterval: 30000 and queueSizeAlertThreshold: 100
2018-05-02 21:52:16.017 TRACE 1108 --- [jgroups-13,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: who-has-sock ip-10-91-133-143-60500
2018-05-02 21:52:16.021 TRACE 1108 --- [jgroups-13,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: received SUSPECT message from ip-10-91-135-48-43121: suspects=[ip-10-91-133-143-60500]
2018-05-02 21:52:16.022 TRACE 1108 --- [jgroups-13,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: received SUSPECT message from ip-10-91-135-48-43121: suspects=[ip-10-91-137-163-65450]
2018-05-02 21:52:16.024 TRACE 1108 --- [jgroups-3,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: received UNSUSPECT message from ip-10-91-135-48-43121: mbrs=[ip-10-91-133-143-60500]
2018-05-02 21:52:16.025 TRACE 1108 --- [jgroups-4,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: received UNSUSPECT message from ip-10-91-135-48-43121: mbrs=[ip-10-91-137-163-65450]
2018-05-02 21:52:16.030 TRACE 1108 --- [jgroups-17,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: received UNSUSPECT message from ip-10-91-137-163-65450: mbrs=[ip-10-91-133-143-60500]
2018-05-02 21:52:16.030 INFO 1108 --- [localhost-startStop-1] c.w.s.c.ServiceClusterCoordinator : - - Detected change in view membership: [ip-10-91-137-163-65450|2] (3) [ip-10-91-137-163-65450, ip-10-91-135-48-43121, ip-10-91-133-143-60500]
2018-05-02 21:52:16.030 INFO 1108 --- [localhost-startStop-1] c.w.s.c.ServiceClusterCoordinator : - - I am not the master!
2018-05-02 21:52:16.031 INFO 1108 --- [localhost-startStop-1] c.w.s.c.ServiceClusterCoordinator : - - ip-10-91-137-163-65450 is the master for service SOM-SKS
2018-05-02 21:52:16.032 INFO 1108 --- [localhost-startStop-1] c.w.s.c.ServiceClusterCoordinator : - - Successfully connected to clusterName: 'SOM-SKS-stage_SJX_290420181509_XSJ'
2018-05-02 21:52:16.032 TRACE 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: got cache from ip-10-91-137-163-65450: cache is ip-10-91-133-143-60500: 10.91.133.143:7804 (0 ms old)
ip-10-91-135-48-43121: 10.91.135.48:7804 (0 ms old)
ip-10-91-137-163-65450: 10.91.137.163:7804 (0 ms old)
2018-05-02 21:52:16.032 TRACE 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: pinger_thread started
2018-05-02 21:52:16.033 DEBUG 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: pingable_mbrs=[ip-10-91-137-163-65450, ip-10-91-135-48-43121, ip-10-91-133-143-60500], ping_dest=ip-10-91-137-163-65450
2018-05-02 21:52:16.035 TRACE 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: ping_dest=ip-10-91-137-163-65450, ping_sock=Socket[addr=/10.91.137.163,port=7804,localport=7805], cache=ip-10-91-133-143-60500: 10.91.133.143:7804 (2 ms old)
ip-10-91-135-48-43121: 10.91.135.48:7804 (2 ms old)
ip-10-91-137-163-65450: 10.91.137.163:7804 (2 ms old)
{color:red}Below logs are generated after terminating the master node from AWS console. I have terminated the EC2 instance. This logs are printed only post 13 seconds after killing the other node.{color}
2018-05-02 21:54:40.040 TRACE 1108 --- [jgroups-17,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.VERIFY_SUSPECT : - - verifying that [ip-10-91-137-163-65450] is dead
2018-05-02 21:54:43.041 TRACE 1108 --- [VERIFY_SUSPECT.TimerThread-19,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.VERIFY_SUSPECT : - - [ip-10-91-137-163-65450] is dead (passing up SUSPECT event)
2018-05-02 21:54:43.202 DEBUG 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: socket to ip-10-91-137-163-65450 was closed gracefully
2018-05-02 21:54:43.203 DEBUG 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: pingable_mbrs=[ip-10-91-135-48-43121, ip-10-91-133-143-60500], ping_dest=ip-10-91-135-48-43121
2018-05-02 21:54:43.203 DEBUG 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: failed connecting to ip-10-91-135-48-43121: Address already in use (Bind failed)
2018-05-02 21:54:43.203 DEBUG 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: broadcasting suspect(ip-10-91-135-48-43121)
2018-05-02 21:54:43.203 TRACE 1108 --- [jgroups-20,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: received SUSPECT message from ip-10-91-133-143-60500: suspects=[ip-10-91-135-48-43121]
2018-05-02 21:54:43.204 DEBUG 1108 --- [jgroups-20,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: suspecting [ip-10-91-135-48-43121]
2018-05-02 21:54:43.204 TRACE 1108 --- [FD_SOCK pinger-14,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: pinger thread terminated
2018-05-02 21:54:43.206 TRACE 1108 --- [jgroups-20,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.VERIFY_SUSPECT : - - verifying that [ip-10-91-135-48-43121] is dead
2018-05-02 21:54:43.208 TRACE 1108 --- [jgroups-20,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.VERIFY_SUSPECT : - - member ip-10-91-135-48-43121 was unsuspected
2018-05-02 21:54:43.208 DEBUG 1108 --- [jgroups-20,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: broadcasting unsuspect(ip-10-91-135-48-43121)
2018-05-02 21:54:43.208 TRACE 1108 --- [jgroups-18,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] org.jgroups.protocols.FD_SOCK : - - ip-10-91-133-143-60500: received UNSUSPECT message from ip-10-91-133-143-60500: mbrs=[ip-10-91-135-48-43121]
2018-05-02 21:54:43.208 INFO 1108 --- [jgroups-17,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] c.w.s.c.ServiceClusterCoordinator : - - Detected change in view membership: [ip-10-91-135-48-43121|3] (2) [ip-10-91-135-48-43121, ip-10-91-133-143-60500]
2018-05-02 21:54:43.209 INFO 1108 --- [jgroups-17,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] c.w.s.c.ServiceClusterCoordinator : - - I am not the master!
2018-05-02 21:54:43.209 INFO 1108 --- [jgroups-17,SOM-SKS-stage_SJX_290420181509_XSJ,ip-10-91-133-143-60500] c.w.s.c.ServiceClusterCoordinator : - - ip-10-91-135-48-43121 is the master for service SOM-SKS
> FD_SOCK is not working in AWS environment
> -----------------------------------------
>
> Key: JGRP-2253
> URL: https://issues.jboss.org/browse/JGRP-2253
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.10
> Environment: AWS - EC2
> Reporter: Sibin Karnavar
> Assignee: Bela Ban
> Fix For: 4.0.12
>
>
> We have our failure detection defined like below.
> <FD_SOCK external_port="7804" />
> <FD timeout="3000" max_tries="3" />
> <VERIFY_SUSPECT timeout="3000" />
> Please note that we have used FD instead of FD_ALL in AWS. We will be changing it to FD_ALL later after detailed testing.
> In my local, this is working perfect. As soon as I kill my node, I was able to see that view change was happening immediately with FD_SOCK.
> We were not mentioning the external_port in the FD_SOCK but later I thought it may be an issue with the port and defined it as 7804 and added the same port to the security group that allows to access this port among all the nodes. So no issue with the port.
> Can you please let us know if we need any additional configurations to make FD_SOCK works well in AWS.
> Thanks,
> Sibin
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-2537) Executable model - kcontext cannot be used as a RuleContext
by Luca Molteni (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2537?page=com.atlassian.jira.plugi... ]
Luca Molteni edited comment on DROOLS-2537 at 5/10/18 10:13 AM:
----------------------------------------------------------------
The DSL is based on `org.drools.model.Drools`, which is a different interface than `org.kie.api.runtime.rule.RuleContext`
At runtime the object passed is an instance of `org.drools.modelcompiler.consequence.DroolsImpl`, which is both an implementation of RuleContext and Drools but as the DSL doesn't know about kie-api someone using it cannot assume the object is of that type.
One thing we could do is to rewrite the method using RuleContext as a parameter using a late binding downcast, something like this
```
public class FactWithRuleContext {
public String getRuleName(final Object ruleContext) {
final RuleContext ruleContext1 = (RuleContext) ruleContext;
return ruleContext1.getRule().getName();
}
}
```
was (Author: volothamp):
The DSL is based on `org.drools.model.Drools`, which is a different interface than `org.kie.api.runtime.rule.RuleContext`
At runtime the object passed is an instance of `org.drools.modelcompiler.consequence.DroolsImpl`, which is both an implementation of RuleContext and Drools but as the DSL doesn't know about kie-api someone using it cannot assume the object is of that type.
One thing we could do is to rewrite the method using RuleContext as a parameter using a late binding downcast, something like this
{{
public class FactWithRuleContext {
public String getRuleName(final Object ruleContext) {
final RuleContext ruleContext1 = (RuleContext) ruleContext;
return ruleContext1.getRule().getName();
}
}
}}
> Executable model - kcontext cannot be used as a RuleContext
> -----------------------------------------------------------
>
> Key: DROOLS-2537
> URL: https://issues.jboss.org/browse/DROOLS-2537
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.7.0.Final
> Reporter: Tibor Zimányi
> Assignee: Mario Fusco
>
> When using kcontext in RHS as a RuleContext, the execution throws incompatible types exception [1]. The problem could be that kcontext is translated to Drools and not to DroolsImpl in the model DSLs.
> PR with a reproducer is here: https://github.com/kiegroup/drools/pull/1896/files#diff-67291fa531041ec60...
> [1] https://gist.github.com/baldimir/94cd43fc10215dd3ef8dad16a0e830d8
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-2537) Executable model - kcontext cannot be used as a RuleContext
by Luca Molteni (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2537?page=com.atlassian.jira.plugi... ]
Luca Molteni edited comment on DROOLS-2537 at 5/10/18 10:12 AM:
----------------------------------------------------------------
The DSL is based on `org.drools.model.Drools`, which is a different interface than `org.kie.api.runtime.rule.RuleContext`
At runtime the object passed is an instance of `org.drools.modelcompiler.consequence.DroolsImpl`, which is both an implementation of RuleContext and Drools but as the DSL doesn't know about kie-api someone using it cannot assume the object is of that type.
One thing we could do is to rewrite the method using RuleContext as a parameter using a late binding downcast, something like this
{{
public class FactWithRuleContext {
public String getRuleName(final Object ruleContext) {
final RuleContext ruleContext1 = (RuleContext) ruleContext;
return ruleContext1.getRule().getName();
}
}
}}
was (Author: volothamp):
The DSL is based on `org.drools.model.Drools`, which is a different interface than `org.kie.api.runtime.rule.RuleContext`
At runtime the object passed is an instance of `org.drools.modelcompiler.consequence.DroolsImpl`, which is both an implementation of RuleContext and Drools but as the DSL doesn't know about kie-api someone using it cannot assume the object is of that type.
One thing we could do is to rewrite the method using RuleContext as a parameter using a late binding downcast, something like this
{{
public class FactWithRuleContext {
public String getRuleName(final Object ruleContext) {
final RuleContext ruleContext1 = (RuleContext) ruleContext;
return ruleContext1.getRule().getName();
}
}}}
> Executable model - kcontext cannot be used as a RuleContext
> -----------------------------------------------------------
>
> Key: DROOLS-2537
> URL: https://issues.jboss.org/browse/DROOLS-2537
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.7.0.Final
> Reporter: Tibor Zimányi
> Assignee: Mario Fusco
>
> When using kcontext in RHS as a RuleContext, the execution throws incompatible types exception [1]. The problem could be that kcontext is translated to Drools and not to DroolsImpl in the model DSLs.
> PR with a reproducer is here: https://github.com/kiegroup/drools/pull/1896/files#diff-67291fa531041ec60...
> [1] https://gist.github.com/baldimir/94cd43fc10215dd3ef8dad16a0e830d8
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-2537) Executable model - kcontext cannot be used as a RuleContext
by Luca Molteni (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2537?page=com.atlassian.jira.plugi... ]
Luca Molteni commented on DROOLS-2537:
--------------------------------------
The DSL is based on `org.drools.model.Drools`, which is a different interface than `org.kie.api.runtime.rule.RuleContext`
At runtime the object passed is an instance of `org.drools.modelcompiler.consequence.DroolsImpl`, which is both an implementation of RuleContext and Drools but as the DSL doesn't know about kie-api someone using it cannot assume the object is of that type.
One thing we could do is to rewrite the method using RuleContext as a parameter using a late binding downcast, something like this
{{
public class FactWithRuleContext {
public String getRuleName(final Object ruleContext) {
final RuleContext ruleContext1 = (RuleContext) ruleContext;
return ruleContext1.getRule().getName();
}
}}}
> Executable model - kcontext cannot be used as a RuleContext
> -----------------------------------------------------------
>
> Key: DROOLS-2537
> URL: https://issues.jboss.org/browse/DROOLS-2537
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.7.0.Final
> Reporter: Tibor Zimányi
> Assignee: Mario Fusco
>
> When using kcontext in RHS as a RuleContext, the execution throws incompatible types exception [1]. The problem could be that kcontext is translated to Drools and not to DroolsImpl in the model DSLs.
> PR with a reproducer is here: https://github.com/kiegroup/drools/pull/1896/files#diff-67291fa531041ec60...
> [1] https://gist.github.com/baldimir/94cd43fc10215dd3ef8dad16a0e830d8
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3819) [GSS](7.1.z) Missing subsystem component to use a custom audit endpoint
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3819?page=com.atlassian.jira.plugi... ]
Jan Kalina moved PRODMGT-1880 to WFCORE-3819:
---------------------------------------------
Project: WildFly Core (was: Product Management)
Key: WFCORE-3819 (was: PRODMGT-1880)
Workflow: GIT Pull Request workflow (was: JBoss Platforms RFE Workflow v2)
Component/s: Security
(was: Enterprise Application Platform (EAP))
Affects Version/s: 5.0.0.Alpha7
(was: 7)
> [GSS](7.1.z) Missing subsystem component to use a custom audit endpoint
> -----------------------------------------------------------------------
>
> Key: WFCORE-3819
> URL: https://issues.jboss.org/browse/WFCORE-3819
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Affects Versions: 5.0.0.Alpha7
> Reporter: Jan Kalina
> Assignee: Jimmy Wilson
>
> Elytron has the ability to create custom audit endpoints to develop your own audit logs. Nevertheless there is no configuration under the {{subsystem=elytron}} to configure a custom audit class (something like {{subsystem=elytron/custom-audit-log=example:add(...}} is needed).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-2542) KieHelper.getKieContainer() is not thread-safe
by Nils Meyer (JIRA)
Nils Meyer created DROOLS-2542:
----------------------------------
Summary: KieHelper.getKieContainer() is not thread-safe
Key: DROOLS-2542
URL: https://issues.jboss.org/browse/DROOLS-2542
Project: Drools
Issue Type: Bug
Affects Versions: 7.7.0.Final
Reporter: Nils Meyer
Assignee: Edson Tirelli
Calling org.kie.api.KieServices.newKieContainer(ReleaseId, ClassLoader), in the way it is done in org.kie.internal.utils.KieHelper.getKieContainer() can cause problems in situations where concurrent threads are in action. newKieContainer reads the latest KieModule from the repository that was written by a builder. If multiple builders for different rules are running in parallel, it's not predictable, which rules will be used when creating a new session (see my sample below).
I'm aware that I can work around this issue by using ReleaseIds, but nevertheless this behavior is cumbersome if you'd like to understand the relation between the KieFileSystem and the KieContainer in org.kie.internal.utils.KieHelper.getKieContainer()
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months