March 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-2409) Memory Leak in sliding window

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2409?page=com.atlassian.jira.plugi... ] Mario Fusco edited comment on DROOLS-2409 at 3/22/18 5:57 AM: -------------------------------------------------------------- I gave a run at your reproducer and I see your point. The problem there is that inserting events in a so tight loop has the effect of overwhelming the engine not giving it a chance of getting any job done. In fact in this case not only the expiration mechanism is not working but also the accumulate rule is not firing at all and your reproducer generates an output as the following: {code} 3500000 inserted into list of 2702077 3510000 inserted into list of 2712077 3520000 inserted into list of 2722077 3530000 inserted into list of 2732077 3540000 inserted into list of 2742077 3550000 inserted into list of 2752077 3560000 inserted into list of 2762077 3570000 inserted into list of 2772077 3580000 inserted into list of 2782077 3590000 inserted into list of 2792077 3600000 inserted into list of 2802077 3610000 inserted into list of 2812077 {code} However I believe that your use case is quite unrealistic. I cannot imagine any real-world application that keeps inserting events forever in a tight all in memory for-loop as in your example. More commonly those events will come for an event bus or a similar data source which at best will be an order of magnitude slower of your for-loop. I expect that Drools will work without any problem in this situation. Indeed just adding a 1ms sleep every 20 inserted events: {code} if (i % 20 == 0) { Thread.sleep( 1L ); } {code} gives the engine enough time to do its job producing the following output: 3500000 inserted into list of 20584 zzZZzz: 49.04286510590858 zzZZzz: 49.040446927374305 zzZZzz: 49.04486607142857 3510000 inserted into list of 15737 zzZZzz: 49.578387458006716 zzZZzz: 49.5359217877095 zzZZzz: 49.540670391061454 3520000 inserted into list of 11409 3530000 inserted into list of 21409 zzZZzz: 49.26767676767677 zzZZzz: 49.34880410022779 zzZZzz: 49.35626423690205 3540000 inserted into list of 16670 zzZZzz: 49.279316338354576 zzZZzz: 49.29466357308585 zzZZzz: 49.29895591647332 3550000 inserted into list of 12099 3560000 inserted into list of 22099 zzZZzz: 49.537780269058295 zzZZzz: 49.60458612975391 zzZZzz: 49.60173184357542 3570000 inserted into list of 18351 zzZZzz: 49.64232062780269 zzZZzz: 49.62682885811985 zzZZzz: 49.62618287698079 3580000 inserted into list of 15067 zzZZzz: 49.538758389261744 zzZZzz: 49.51251396648045 zzZZzz: 49.503407821229054 3590000 inserted into list of 12190 3600000 inserted into list of 22190 zzZZzz: 49.426733622975796 zzZZzz: 49.446553672316384 zzZZzz: 49.44441309255079 3610000 inserted into list of 19332 As you can see in this case the engine is now having time to fire the rule and by doing so it is also evicting the expired objects from the working memory as expected. I'm not saying that we don't have a problem here. I'll keep investigating your test case to check if I can make this work in a more reliable way even in this extreme scenario. Any further feedback is welcome. was (Author: mfusco): I gave a run at your reproducer and I see your point. The problem there is that inserting events in a so tight loop has the effect of overwhelming the engine not giving it a chance of getting any job done. In fact in this case not only the expiration mechanism is not working but also the accumulate rule is not firing at all and your reproducer generates an output as the following: {code} 3500000 inserted into list of 2702077 3510000 inserted into list of 2712077 3520000 inserted into list of 2722077 3530000 inserted into list of 2732077 3540000 inserted into list of 2742077 3550000 inserted into list of 2752077 3560000 inserted into list of 2762077 3570000 inserted into list of 2772077 3580000 inserted into list of 2782077 3590000 inserted into list of 2792077 3600000 inserted into list of 2802077 3610000 inserted into list of 2812077 {code} However I believe that your use case is quite unrealistic. I cannot imagine any real-world application that keeps inserting events forever in a tight all in memory for-loop as in your example. More commonly those events will come for an event bus or a similar data source which at best will be an order of magnitude slower of your for-loop. I expect that Drools will work without any problem in this situation. Indeed just adding a 1ms sleep every 20 inserted events: {code} if (i % 20 == 0) { Thread.sleep( 1L ); } {code} gives the engine enough time to do its job producing the following output: {code} 3500000 inserted into list of 20584 zzZZzz: 49.04286510590858 zzZZzz: 49.040446927374305 zzZZzz: 49.04486607142857 3510000 inserted into list of 15737 zzZZzz: 49.578387458006716 zzZZzz: 49.5359217877095 zzZZzz: 49.540670391061454 3520000 inserted into list of 11409 3530000 inserted into list of 21409 zzZZzz: 49.26767676767677 zzZZzz: 49.34880410022779 zzZZzz: 49.35626423690205 3540000 inserted into list of 16670 zzZZzz: 49.279316338354576 zzZZzz: 49.29466357308585 zzZZzz: 49.29895591647332 3550000 inserted into list of 12099 3560000 inserted into list of 22099 zzZZzz: 49.537780269058295 zzZZzz: 49.60458612975391 zzZZzz: 49.60173184357542 3570000 inserted into list of 18351 zzZZzz: 49.64232062780269 zzZZzz: 49.62682885811985 zzZZzz: 49.62618287698079 3580000 inserted into list of 15067 zzZZzz: 49.538758389261744 zzZZzz: 49.51251396648045 zzZZzz: 49.503407821229054 3590000 inserted into list of 12190 3600000 inserted into list of 22190 zzZZzz: 49.426733622975796 zzZZzz: 49.446553672316384 zzZZzz: 49.44441309255079 3610000 inserted into list of 19332 {code] As you can see in this case the engine is now having time to fire the rule and by doing so it is also evicting the expired objects from the working memory as expected. I'm not saying that we don't have a problem here. I'll keep investigating your test case to check if I can make this work in a more reliable way even in this extreme scenario. Any further feedback is welcome. > Memory Leak in sliding window > ----------------------------- > > Key: DROOLS-2409 > URL: https://issues.jboss.org/browse/DROOLS-2409 > Project: Drools > Issue Type: Feature Request > Components: core engine > Affects Versions: 7.6.0.Final > Environment: Mac with Java 1.8 using Spring Boot (see attached demo project) > Reporter: Mike Baranski > Assignee: Mario Fusco > Priority: Critical > Attachments: complete.tar.gz > > > See attached project. > `gradle test` causes an out of memory exception on my machine after ~2.6 million events. Events should be released for GC after 1 second, but that does not appear to be happening. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-2409) Memory Leak in sliding window

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2409?page=com.atlassian.jira.plugi... ] Mario Fusco edited comment on DROOLS-2409 at 3/22/18 5:57 AM: -------------------------------------------------------------- I gave a run at your reproducer and I see your point. The problem there is that inserting events in a so tight loop has the effect of overwhelming the engine not giving it a chance of getting any job done. In fact in this case not only the expiration mechanism is not working but also the accumulate rule is not firing at all and your reproducer generates an output as the following: {code} 3500000 inserted into list of 2702077 3510000 inserted into list of 2712077 3520000 inserted into list of 2722077 3530000 inserted into list of 2732077 3540000 inserted into list of 2742077 3550000 inserted into list of 2752077 3560000 inserted into list of 2762077 3570000 inserted into list of 2772077 3580000 inserted into list of 2782077 3590000 inserted into list of 2792077 3600000 inserted into list of 2802077 3610000 inserted into list of 2812077 {code} However I believe that your use case is quite unrealistic. I cannot imagine any real-world application that keeps inserting events forever in a tight all in memory for-loop as in your example. More commonly those events will come for an event bus or a similar data source which at best will be an order of magnitude slower of your for-loop. I expect that Drools will work without any problem in this situation. Indeed just adding a 1ms sleep every 20 inserted events: {code} if (i % 20 == 0) { Thread.sleep( 1L ); } {code} gives the engine enough time to do its job producing the following output: {code} 3500000 inserted into list of 20584 zzZZzz: 49.04286510590858 zzZZzz: 49.040446927374305 zzZZzz: 49.04486607142857 3510000 inserted into list of 15737 zzZZzz: 49.578387458006716 zzZZzz: 49.5359217877095 zzZZzz: 49.540670391061454 3520000 inserted into list of 11409 3530000 inserted into list of 21409 zzZZzz: 49.26767676767677 zzZZzz: 49.34880410022779 zzZZzz: 49.35626423690205 3540000 inserted into list of 16670 zzZZzz: 49.279316338354576 zzZZzz: 49.29466357308585 zzZZzz: 49.29895591647332 3550000 inserted into list of 12099 3560000 inserted into list of 22099 zzZZzz: 49.537780269058295 zzZZzz: 49.60458612975391 zzZZzz: 49.60173184357542 3570000 inserted into list of 18351 zzZZzz: 49.64232062780269 zzZZzz: 49.62682885811985 zzZZzz: 49.62618287698079 3580000 inserted into list of 15067 zzZZzz: 49.538758389261744 zzZZzz: 49.51251396648045 zzZZzz: 49.503407821229054 3590000 inserted into list of 12190 3600000 inserted into list of 22190 zzZZzz: 49.426733622975796 zzZZzz: 49.446553672316384 zzZZzz: 49.44441309255079 3610000 inserted into list of 19332 {code] As you can see in this case the engine is now having time to fire the rule and by doing so it is also evicting the expired objects from the working memory as expected. I'm not saying that we don't have a problem here. I'll keep investigating your test case to check if I can make this work in a more reliable way even in this extreme scenario. Any further feedback is welcome. was (Author: mfusco): I gave a run at your reproducer and I see your point. The problem there is that inserting events in a so tight loop has the effect of overwhelming the engine not giving it a chance of getting any job done. In fact in this case not only the expiration mechanism is not working but also the accumulate rule is not firing at all and your reproducer generates an output as the following: {code} 3500000 inserted into list of 2702077 3510000 inserted into list of 2712077 3520000 inserted into list of 2722077 3530000 inserted into list of 2732077 3540000 inserted into list of 2742077 3550000 inserted into list of 2752077 3560000 inserted into list of 2762077 3570000 inserted into list of 2772077 3580000 inserted into list of 2782077 3590000 inserted into list of 2792077 3600000 inserted into list of 2802077 3610000 inserted into list of 2812077 {code} However I believe that your use case is quite unrealistic. I cannot imagine any real-world application that keeps inserting events forever in a tight all in memory for-loop as in your example. More commonly those events will come for an event bus or a similar data source which at best will be an order of magnitude slower of your for-loop. I expect that Drools will work without any problem in this situation. Indeed just adding a 1ms sleep every 20 inserted events: {code} if (i % 20 == 0) { Thread.sleep( 1L ); } {code} gives the engine enough time to do its job producing the following output: {code} 3500000 inserted into list of 20584 zzZZzz: 49.04286510590858 zzZZzz: 49.040446927374305 zzZZzz: 49.04486607142857 3510000 inserted into list of 15737 zzZZzz: 49.578387458006716 zzZZzz: 49.5359217877095 zzZZzz: 49.540670391061454 3520000 inserted into list of 11409 3530000 inserted into list of 21409 zzZZzz: 49.26767676767677 zzZZzz: 49.34880410022779 zzZZzz: 49.35626423690205 3540000 inserted into list of 16670 zzZZzz: 49.279316338354576 zzZZzz: 49.29466357308585 zzZZzz: 49.29895591647332 3550000 inserted into list of 12099 3560000 inserted into list of 22099 zzZZzz: 49.537780269058295 zzZZzz: 49.60458612975391 zzZZzz: 49.60173184357542 3570000 inserted into list of 18351 zzZZzz: 49.64232062780269 zzZZzz: 49.62682885811985 zzZZzz: 49.62618287698079 3580000 inserted into list of 15067 zzZZzz: 49.538758389261744 zzZZzz: 49.51251396648045 zzZZzz: 49.503407821229054 3590000 inserted into list of 12190 3600000 inserted into list of 22190 zzZZzz: 49.426733622975796 zzZZzz: 49.446553672316384 zzZZzz: 49.44441309255079 3610000 inserted into list of 19332 {code] As you can see in this case the engine is now having time to fire the rule and by doing so it is also evicting the expired objects from the working memory as expected. I'm not saying that we don't have a problem here. I'll keep investigating your test case to check if I can make this work in a more reliable way even in this extreme scenario. Any further feedback is welcome. > Memory Leak in sliding window > ----------------------------- > > Key: DROOLS-2409 > URL: https://issues.jboss.org/browse/DROOLS-2409 > Project: Drools > Issue Type: Feature Request > Components: core engine > Affects Versions: 7.6.0.Final > Environment: Mac with Java 1.8 using Spring Boot (see attached demo project) > Reporter: Mike Baranski > Assignee: Mario Fusco > Priority: Critical > Attachments: complete.tar.gz > > > See attached project. > `gradle test` causes an out of memory exception on my machine after ~2.6 million events. Events should be released for GC after 1 second, but that does not appear to be happening. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-2409) Memory Leak in sliding window

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2409?page=com.atlassian.jira.plugi... ] Mario Fusco edited comment on DROOLS-2409 at 3/22/18 5:56 AM: -------------------------------------------------------------- I gave a run at your reproducer and I see your point. The problem there is that inserting events in a so tight loop has the effect of overwhelming the engine not giving it a chance of getting any job done. In fact in this case not only the expiration mechanism is not working but also the accumulate rule is not firing at all and your reproducer generates an output as the following: {code} 3500000 inserted into list of 2702077 3510000 inserted into list of 2712077 3520000 inserted into list of 2722077 3530000 inserted into list of 2732077 3540000 inserted into list of 2742077 3550000 inserted into list of 2752077 3560000 inserted into list of 2762077 3570000 inserted into list of 2772077 3580000 inserted into list of 2782077 3590000 inserted into list of 2792077 3600000 inserted into list of 2802077 3610000 inserted into list of 2812077 {code} However I believe that your use case is quite unrealistic. I cannot imagine any real-world application that keeps inserting events forever in a tight all in memory for-loop as in your example. More commonly those events will come for an event bus or a similar data source which at best will be an order of magnitude slower of your for-loop. I expect that Drools will work without any problem in this situation. Indeed just adding a 1ms sleep every 20 inserted events: {code} if (i % 20 == 0) { Thread.sleep( 1L ); } {code} gives the engine enough time to do its job producing the following output: {code} 3500000 inserted into list of 20584 zzZZzz: 49.04286510590858 zzZZzz: 49.040446927374305 zzZZzz: 49.04486607142857 3510000 inserted into list of 15737 zzZZzz: 49.578387458006716 zzZZzz: 49.5359217877095 zzZZzz: 49.540670391061454 3520000 inserted into list of 11409 3530000 inserted into list of 21409 zzZZzz: 49.26767676767677 zzZZzz: 49.34880410022779 zzZZzz: 49.35626423690205 3540000 inserted into list of 16670 zzZZzz: 49.279316338354576 zzZZzz: 49.29466357308585 zzZZzz: 49.29895591647332 3550000 inserted into list of 12099 3560000 inserted into list of 22099 zzZZzz: 49.537780269058295 zzZZzz: 49.60458612975391 zzZZzz: 49.60173184357542 3570000 inserted into list of 18351 zzZZzz: 49.64232062780269 zzZZzz: 49.62682885811985 zzZZzz: 49.62618287698079 3580000 inserted into list of 15067 zzZZzz: 49.538758389261744 zzZZzz: 49.51251396648045 zzZZzz: 49.503407821229054 3590000 inserted into list of 12190 3600000 inserted into list of 22190 zzZZzz: 49.426733622975796 zzZZzz: 49.446553672316384 zzZZzz: 49.44441309255079 3610000 inserted into list of 19332 {code] As you can see in this case the engine is now having time to fire the rule and by doing so it is also evicting the expired objects from the working memory as expected. I'm not saying that we don't have a problem here. I'll keep investigating your test case to check if I can make this work in a more reliable way even in this extreme scenario. Any further feedback is welcome. was (Author: mfusco): I gave a run at your reproducer and I see your point. The problem there is that inserting events in a so tight loop has the effect of overwhelming the engine not giving it a chance of getting any job done. In fact in this case not only the expiration mechanism is not working but also the accumulate rule is not firing at all and your reproducer generates an output as the following: {source} 3500000 inserted into list of 2702077 3510000 inserted into list of 2712077 3520000 inserted into list of 2722077 3530000 inserted into list of 2732077 3540000 inserted into list of 2742077 3550000 inserted into list of 2752077 3560000 inserted into list of 2762077 3570000 inserted into list of 2772077 3580000 inserted into list of 2782077 3590000 inserted into list of 2792077 3600000 inserted into list of 2802077 3610000 inserted into list of 2812077 {source} However I believe that your use case is quite unrealistic. I cannot imagine any real-world application that keeps inserting events forever in a tight all in memory for-loop as in your example. More commonly those events will come for an event bus or a similar data source which at best will be an order of magnitude slower of your for-loop. I expect that Drools will work without any problem in this situation. Indeed just adding a 1ms sleep every 20 inserted events: {code} if (i % 20 == 0) { Thread.sleep( 1L ); } {code} gives the engine enough time to do its job producing the following output: {code} 3500000 inserted into list of 20584 zzZZzz: 49.04286510590858 zzZZzz: 49.040446927374305 zzZZzz: 49.04486607142857 3510000 inserted into list of 15737 zzZZzz: 49.578387458006716 zzZZzz: 49.5359217877095 zzZZzz: 49.540670391061454 3520000 inserted into list of 11409 3530000 inserted into list of 21409 zzZZzz: 49.26767676767677 zzZZzz: 49.34880410022779 zzZZzz: 49.35626423690205 3540000 inserted into list of 16670 zzZZzz: 49.279316338354576 zzZZzz: 49.29466357308585 zzZZzz: 49.29895591647332 3550000 inserted into list of 12099 3560000 inserted into list of 22099 zzZZzz: 49.537780269058295 zzZZzz: 49.60458612975391 zzZZzz: 49.60173184357542 3570000 inserted into list of 18351 zzZZzz: 49.64232062780269 zzZZzz: 49.62682885811985 zzZZzz: 49.62618287698079 3580000 inserted into list of 15067 zzZZzz: 49.538758389261744 zzZZzz: 49.51251396648045 zzZZzz: 49.503407821229054 3590000 inserted into list of 12190 3600000 inserted into list of 22190 zzZZzz: 49.426733622975796 zzZZzz: 49.446553672316384 zzZZzz: 49.44441309255079 3610000 inserted into list of 19332 {code] As you can see in this case the engine is now having time to fire the rule and by doing so it is also evicting the expired objects from the working memory as expected. I'm not saying that we don't have a problem here. I'll keep investigating your test case to check if I can make this work in a more reliable way even in this extreme scenario. Any further feedback is welcome. > Memory Leak in sliding window > ----------------------------- > > Key: DROOLS-2409 > URL: https://issues.jboss.org/browse/DROOLS-2409 > Project: Drools > Issue Type: Feature Request > Components: core engine > Affects Versions: 7.6.0.Final > Environment: Mac with Java 1.8 using Spring Boot (see attached demo project) > Reporter: Mike Baranski > Assignee: Mario Fusco > Priority: Critical > Attachments: complete.tar.gz > > > See attached project. > `gradle test` causes an out of memory exception on my machine after ~2.6 million events. Events should be released for GC after 1 second, but that does not appear to be happening. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-2409) Memory Leak in sliding window

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2409?page=com.atlassian.jira.plugi... ] Mario Fusco commented on DROOLS-2409: ------------------------------------- I gave a run at your reproducer and I see your point. The problem there is that inserting events in a so tight loop has the effect of overwhelming the engine not giving it a chance of getting any job done. In fact in this case not only the expiration mechanism is not working but also the accumulate rule is not firing at all and your reproducer generates an output as the following: {source} 3500000 inserted into list of 2702077 3510000 inserted into list of 2712077 3520000 inserted into list of 2722077 3530000 inserted into list of 2732077 3540000 inserted into list of 2742077 3550000 inserted into list of 2752077 3560000 inserted into list of 2762077 3570000 inserted into list of 2772077 3580000 inserted into list of 2782077 3590000 inserted into list of 2792077 3600000 inserted into list of 2802077 3610000 inserted into list of 2812077 {source} However I believe that your use case is quite unrealistic. I cannot imagine any real-world application that keeps inserting events forever in a tight all in memory for-loop as in your example. More commonly those events will come for an event bus or a similar data source which at best will be an order of magnitude slower of your for-loop. I expect that Drools will work without any problem in this situation. Indeed just adding a 1ms sleep every 20 inserted events: {code} if (i % 20 == 0) { Thread.sleep( 1L ); } {code} gives the engine enough time to do its job producing the following output: {code} 3500000 inserted into list of 20584 zzZZzz: 49.04286510590858 zzZZzz: 49.040446927374305 zzZZzz: 49.04486607142857 3510000 inserted into list of 15737 zzZZzz: 49.578387458006716 zzZZzz: 49.5359217877095 zzZZzz: 49.540670391061454 3520000 inserted into list of 11409 3530000 inserted into list of 21409 zzZZzz: 49.26767676767677 zzZZzz: 49.34880410022779 zzZZzz: 49.35626423690205 3540000 inserted into list of 16670 zzZZzz: 49.279316338354576 zzZZzz: 49.29466357308585 zzZZzz: 49.29895591647332 3550000 inserted into list of 12099 3560000 inserted into list of 22099 zzZZzz: 49.537780269058295 zzZZzz: 49.60458612975391 zzZZzz: 49.60173184357542 3570000 inserted into list of 18351 zzZZzz: 49.64232062780269 zzZZzz: 49.62682885811985 zzZZzz: 49.62618287698079 3580000 inserted into list of 15067 zzZZzz: 49.538758389261744 zzZZzz: 49.51251396648045 zzZZzz: 49.503407821229054 3590000 inserted into list of 12190 3600000 inserted into list of 22190 zzZZzz: 49.426733622975796 zzZZzz: 49.446553672316384 zzZZzz: 49.44441309255079 3610000 inserted into list of 19332 {code] As you can see in this case the engine is now having time to fire the rule and by doing so it is also evicting the expired objects from the working memory as expected. I'm not saying that we don't have a problem here. I'll keep investigating your test case to check if I can make this work in a more reliable way even in this extreme scenario. Any further feedback is welcome. > Memory Leak in sliding window > ----------------------------- > > Key: DROOLS-2409 > URL: https://issues.jboss.org/browse/DROOLS-2409 > Project: Drools > Issue Type: Feature Request > Components: core engine > Affects Versions: 7.6.0.Final > Environment: Mac with Java 1.8 using Spring Boot (see attached demo project) > Reporter: Mike Baranski > Assignee: Mario Fusco > Priority: Critical > Attachments: complete.tar.gz > > > See attached project. > `gradle test` causes an out of memory exception on my machine after ~2.6 million events. Events should be released for GC after 1 second, but that does not appear to be happening. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1891) Guided decision table: Add menu option on toolbar for "auto-expansion" of conditions

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1891?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-1891: -------------------------------- Fix Version/s: (was: 7.7.0.Final) > Guided decision table: Add menu option on toolbar for "auto-expansion" of conditions > ------------------------------------------------------------------------------------ > > Key: DROOLS-1891 > URL: https://issues.jboss.org/browse/DROOLS-1891 > Project: Drools > Issue Type: Sub-task > Components: Guided Decision Table Editor > Affects Versions: 5.5.0.Final > Reporter: Michael Anstis > Assignee: Michael Anstis > > You can elect to create an expanded decision table when using the Wizard, however it should be possible to expand from the asset editor. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1858) Guided decision table: Add support for automatic expansion and contraction.

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1858?page=com.atlassian.jira.plugi... ] Jozef Marko commented on DROOLS-1858: ------------------------------------- [~manstis] thanks > Guided decision table: Add support for automatic expansion and contraction. > --------------------------------------------------------------------------- > > Key: DROOLS-1858 > URL: https://issues.jboss.org/browse/DROOLS-1858 > Project: Drools > Issue Type: Feature Request > Components: Guided Decision Table Editor > Reporter: Michael Anstis > Assignee: Guilherme Carreiro > Attachments: Screenshot from 2018-03-22 10-17-32.png > > > Add support for expansion of guided decision table's condition columns (where they are defined as an enum - Java or "Guvnor" enum). Also add support for contraction of condition columns. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1846) Allow real time verification of Fact's constraints in Guided Editor

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1846?page=com.atlassian.jira.plugi... ] Jozef Marko closed DROOLS-1846. ------------------------------- Resolution: Won't Fix > Allow real time verification of Fact's constraints in Guided Editor > ------------------------------------------------------------------- > > Key: DROOLS-1846 > URL: https://issues.jboss.org/browse/DROOLS-1846 > Project: Drools > Issue Type: Feature Request > Components: Guided Decision Table Editor, Guided Rule Editor, Guided Template Editor > Reporter: Esteban Aliverti > Assignee: Guilherme Carreiro > Priority: Minor > Labels: guvnor, real_time, real_time_verification > Fix For: 7.7.0.Final > > > It would be good to have real time validation of Fact's Constraints in Guvnor's Guided Editor. > We can use the same verifier rules created by the constraints that are used right now in the "on demand" verification. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10069) Remove all slf4j dependencies from WildFly

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-10069?page=com.atlassian.jira.plugin... ] Jeff Mesnil updated WFLY-10069: ------------------------------- Summary: Remove all slf4j dependencies from WildFly (was: Move all slf4j modules to WildFly Core) > Remove all slf4j dependencies from WildFly > ------------------------------------------ > > Key: WFLY-10069 > URL: https://issues.jboss.org/browse/WFLY-10069 > Project: WildFly > Issue Type: Task > Components: Build System > Affects Versions: 12.0.0.Final > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > > Most of SLF4J dependencies are defined are in wildfly-core except for slf4j-ext. > There are also transitive dependencies to jcl-over-slf4j for the JMS client BoM that requires to specify the version of SL4F in wildfly. > The goal of this task is to move all SLF4J dependencies in wildlfy-core that will be the only and authoritative location to specify the version of SLF4J used in WildFly app server. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-3703) Move all slf4j modules to WildFly Core

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3703?page=com.atlassian.jira.plugi... ] Jeff Mesnil moved WFLY-10071 to WFCORE-3703: -------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-3703 (was: WFLY-10071) Component/s: Server (was: Build System) Affects Version/s: (was: 12.0.0.Final) > Move all slf4j modules to WildFly Core > -------------------------------------- > > Key: WFCORE-3703 > URL: https://issues.jboss.org/browse/WFCORE-3703 > Project: WildFly Core > Issue Type: Task > Components: Server > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > > Most of SLF4J dependencies are defined are in wildfly-core except for slf4j-ext. > There are also transitive dependencies to jcl-over-slf4j for the JMS client BoM that requires to specify the version of SL4F in wildfly. > The goal of this task is to move all SLF4J dependencies in wildlfy-core that will be the only and authoritative location to specify the version of SLF4J used in WildFly app server. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10071) Move all slf4j modules to WildFly Core

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFLY-10071: ---------------------------------- Summary: Move all slf4j modules to WildFly Core Key: WFLY-10071 URL: https://issues.jboss.org/browse/WFLY-10071 Project: WildFly Issue Type: Task Components: Build System Affects Versions: 12.0.0.Final Reporter: Jeff Mesnil Assignee: Jeff Mesnil Most of SLF4J dependencies are defined are in wildfly-core except for slf4j-ext. There are also transitive dependencies to jcl-over-slf4j for the JMS client BoM that requires to specify the version of SL4F in wildfly. The goal of this task is to move all SLF4J dependencies in wildlfy-core that will be the only and authoritative location to specify the version of SLF4J used in WildFly app server. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 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 2018