[JBoss JIRA] (DROOLS-5620) SerializedPackageMergeTwoSteps2Test random failure
by Daniel Rosa (Jira)
[ https://issues.redhat.com/browse/DROOLS-5620?page=com.atlassian.jira.plug... ]
Daniel Rosa updated DROOLS-5620:
--------------------------------
Sprint: 2020 Week 37-39 (from Sep 7)
> SerializedPackageMergeTwoSteps2Test random failure
> --------------------------------------------------
>
> Key: DROOLS-5620
> URL: https://issues.redhat.com/browse/DROOLS-5620
> Project: Drools
> Issue Type: Bug
> Reporter: Daniel Rosa
> Assignee: Daniel Rosa
> Priority: Minor
>
> org.drools.compiler.integrationtests.
> SerializedPackageMergeTwoSteps2Test.testBuildAndSerializePackagesInTwoSteps2
> Failed on [7.39.x daily build #74|https://rhba-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/KIE/job/7.39.x/job/daily-build-prod/job/daily-build-prod-pipeline-7.39.x/74/testReport/junit/org.drools.compiler.integrationtests/SerializedPackageMergeTwoSteps2Test/testBuildAndSerializePackagesInTwoSteps2/] with java.io.EOFException.
> The EOFException is raised when the resource files provided by the first step class (SerializedPackageMergeTwoSteps1Test) are not ready for the second class (SerializedPackageMergeTwoSteps2Test) to consume them.
> It happened on #74 build that the second class tried to consume the files faster than the first class was able to finish writing them on disk.
> The QE community test jobs ([this one for instance|https://rhba-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/BxMS...]) passed for 7.8.1 build.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (DROOLS-5631) Rule evaluation optimization
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5631?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi updated DROOLS-5631:
--------------------------------------
Description:
Motivation: This Story aims at rule evaluation optimization so both Kogito and drools core engine usage will get benefits for overall rule execution. It contains Alpha Node Ordering to maximize sharing and minimize the number of evaluations, Range Indexing (I will file and link later). Other JIRAs may be added later.
Goals: Better rule execution performance. For each improvement, add benchmark and measure the performance gain.
Impact: Better rule execution performance. It might have overhead during rule build time. Will confirm with benchmark anyway.
was:
Motivation: This Story aims at rule evaluation optimization so both Kogito and drools core engine usage will get benefits for overall rule execution. It contains Alpha Node Ordering to maximize sharing and minimize the number of evaluations, Range Indexing (may add more).
Goals: Better rule execution performance. For each improvement, add benchmark and measure the performance gain.
Impact: Better rule execution performance. It might have overhead during rule build time. Will confirm with benchmark anyway.
> Rule evaluation optimization
> ----------------------------
>
> Key: DROOLS-5631
> URL: https://issues.redhat.com/browse/DROOLS-5631
> Project: Drools
> Issue Type: Story
> Components: core engine
> Affects Versions: 7.42.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> Motivation: This Story aims at rule evaluation optimization so both Kogito and drools core engine usage will get benefits for overall rule execution. It contains Alpha Node Ordering to maximize sharing and minimize the number of evaluations, Range Indexing (I will file and link later). Other JIRAs may be added later.
> Goals: Better rule execution performance. For each improvement, add benchmark and measure the performance gain.
> Impact: Better rule execution performance. It might have overhead during rule build time. Will confirm with benchmark anyway.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-13828) remote+tls is not supported by EJBClient and remote-outbound-connection
by Matthias Großmann (Jira)
[ https://issues.redhat.com/browse/WFLY-13828?page=com.atlassian.jira.plugi... ]
Matthias Großmann updated WFLY-13828:
-------------------------------------
Description:
Hi,
in our company we would like to use the newest Wildfly together with legacy servers like JBoss AS 7 over SSL.
This is possible with the Uri scheme "remote+tls" provided by jboss-remoting
https://github.com/jboss-remoting/jboss-remoting/blob/master/src/main/jav...
{code:java}
final RemoteConnectionProviderFactory remoteConnectionProviderFactory = new RemoteConnectionProviderFactory();
...
endpoint.addConnectionProvider("remote+tls", remoteConnectionProviderFactory, OptionMap.create(Options.SECURE, Boolean.TRUE));
{code}
But that uri scheme is not supported by the jboss-ejb-client in current version
https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
{code}
public boolean supportsProtocol(final String uriScheme) {
switch (uriScheme) {
case "remote":
case "remote+http":
case "remote+https":
// compatibility
case "remoting":
case "http-remoting":
case "https-remoting": {
return true;
}
default: {
return false;
}
}
}
{code}
and also the remote-outbound-connection does not allow that protocol:
https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/sr...
{code}
public enum Protocol {
REMOTE("remote"),
REMOTE_HTTP("remote+http"),
HTTP_REMOTING("http-remoting"),
HTTPS_REMOTING("https-remoting"),
REMOTE_HTTPS("remote+https");
{code}
was:
Hi,
in our company we would like to use the newest Wildfly together with legacy servers like Jboss 7 over SSL.
This is possible with the Uri scheme "remote+tls" provided by jboss-remoting
https://github.com/jboss-remoting/jboss-remoting/blob/master/src/main/jav...
{code:java}
final RemoteConnectionProviderFactory remoteConnectionProviderFactory = new RemoteConnectionProviderFactory();
...
endpoint.addConnectionProvider("remote+tls", remoteConnectionProviderFactory, OptionMap.create(Options.SECURE, Boolean.TRUE));
{code}
But that uri scheme is not supported by the jboss-ejb-client in current version
https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
{code}
public boolean supportsProtocol(final String uriScheme) {
switch (uriScheme) {
case "remote":
case "remote+http":
case "remote+https":
// compatibility
case "remoting":
case "http-remoting":
case "https-remoting": {
return true;
}
default: {
return false;
}
}
}
{code}
and also the remote-outbound-connection does not allow that protocol:
https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/sr...
{code}
public enum Protocol {
REMOTE("remote"),
REMOTE_HTTP("remote+http"),
HTTP_REMOTING("http-remoting"),
HTTPS_REMOTING("https-remoting"),
REMOTE_HTTPS("remote+https");
{code}
> remote+tls is not supported by EJBClient and remote-outbound-connection
> -----------------------------------------------------------------------
>
> Key: WFLY-13828
> URL: https://issues.redhat.com/browse/WFLY-13828
> Project: WildFly
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 20.0.1.Final
> Reporter: Matthias Großmann
> Assignee: Flavia Rainone
> Priority: Major
>
> Hi,
> in our company we would like to use the newest Wildfly together with legacy servers like JBoss AS 7 over SSL.
> This is possible with the Uri scheme "remote+tls" provided by jboss-remoting
> https://github.com/jboss-remoting/jboss-remoting/blob/master/src/main/jav...
> {code:java}
> final RemoteConnectionProviderFactory remoteConnectionProviderFactory = new RemoteConnectionProviderFactory();
> ...
> endpoint.addConnectionProvider("remote+tls", remoteConnectionProviderFactory, OptionMap.create(Options.SECURE, Boolean.TRUE));
> {code}
> But that uri scheme is not supported by the jboss-ejb-client in current version
> https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
> {code}
> public boolean supportsProtocol(final String uriScheme) {
> switch (uriScheme) {
> case "remote":
> case "remote+http":
> case "remote+https":
> // compatibility
> case "remoting":
> case "http-remoting":
> case "https-remoting": {
> return true;
> }
> default: {
> return false;
> }
> }
> }
> {code}
> and also the remote-outbound-connection does not allow that protocol:
> https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/sr...
> {code}
> public enum Protocol {
> REMOTE("remote"),
> REMOTE_HTTP("remote+http"),
> HTTP_REMOTING("http-remoting"),
> HTTPS_REMOTING("https-remoting"),
> REMOTE_HTTPS("remote+https");
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-13828) remote+tls is not supported by EJBClient and remote-outbound-connection
by Matthias Großmann (Jira)
[ https://issues.redhat.com/browse/WFLY-13828?page=com.atlassian.jira.plugi... ]
Matthias Großmann updated WFLY-13828:
-------------------------------------
Description:
Hi,
in our company we would like to use the newest Wildfly together with legacy servers like Jboss 7 over SSL.
This is possible with the Uri scheme "remote+tls" provided by jboss-remoting
https://github.com/jboss-remoting/jboss-remoting/blob/master/src/main/jav...
{code:java}
final RemoteConnectionProviderFactory remoteConnectionProviderFactory = new RemoteConnectionProviderFactory();
...
endpoint.addConnectionProvider("remote+tls", remoteConnectionProviderFactory, OptionMap.create(Options.SECURE, Boolean.TRUE));
{code}
But that uri scheme is not supported by the jboss-ejb-client in current version
https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
{code}
public boolean supportsProtocol(final String uriScheme) {
switch (uriScheme) {
case "remote":
case "remote+http":
case "remote+https":
// compatibility
case "remoting":
case "http-remoting":
case "https-remoting": {
return true;
}
default: {
return false;
}
}
}
{code}
and also the remote-outbound-connection does not allow that protocol:
https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/sr...
{code}
public enum Protocol {
REMOTE("remote"),
REMOTE_HTTP("remote+http"),
HTTP_REMOTING("http-remoting"),
HTTPS_REMOTING("https-remoting"),
REMOTE_HTTPS("remote+https");
{code}
was:
Hi,
in our company we would like to use the newest Wildfly together with legacy servers like Jboss 7 over SSL.
This is possible with the Uri scheme "remote+tls" provided by jboss-remoting
https://github.com/jboss-remoting/jboss-remoting/blob/master/src/main/jav...
{code:java}
// remote (SSL is explicit in URL)
final RemoteConnectionProviderFactory remoteConnectionProviderFactory = new RemoteConnectionProviderFactory();
...
endpoint.addConnectionProvider("remote+tls", remoteConnectionProviderFactory, OptionMap.create(Options.SECURE, Boolean.TRUE));
{code}
But that uri scheme is not supported by the jboss-ejb-client in current version
https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
{code}
public boolean supportsProtocol(final String uriScheme) {
switch (uriScheme) {
case "remote":
case "remote+http":
case "remote+https":
// compatibility
case "remoting":
case "http-remoting":
case "https-remoting": {
return true;
}
default: {
return false;
}
}
}
{code}
and also the remote-outbound-connection does not allow that protocol:
https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/sr...
{code}
public enum Protocol {
REMOTE("remote"),
REMOTE_HTTP("remote+http"),
HTTP_REMOTING("http-remoting"),
HTTPS_REMOTING("https-remoting"),
REMOTE_HTTPS("remote+https");
{code}
> remote+tls is not supported by EJBClient and remote-outbound-connection
> -----------------------------------------------------------------------
>
> Key: WFLY-13828
> URL: https://issues.redhat.com/browse/WFLY-13828
> Project: WildFly
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 20.0.1.Final
> Reporter: Matthias Großmann
> Assignee: Flavia Rainone
> Priority: Major
>
> Hi,
> in our company we would like to use the newest Wildfly together with legacy servers like Jboss 7 over SSL.
> This is possible with the Uri scheme "remote+tls" provided by jboss-remoting
> https://github.com/jboss-remoting/jboss-remoting/blob/master/src/main/jav...
> {code:java}
> final RemoteConnectionProviderFactory remoteConnectionProviderFactory = new RemoteConnectionProviderFactory();
> ...
> endpoint.addConnectionProvider("remote+tls", remoteConnectionProviderFactory, OptionMap.create(Options.SECURE, Boolean.TRUE));
> {code}
> But that uri scheme is not supported by the jboss-ejb-client in current version
> https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
> {code}
> public boolean supportsProtocol(final String uriScheme) {
> switch (uriScheme) {
> case "remote":
> case "remote+http":
> case "remote+https":
> // compatibility
> case "remoting":
> case "http-remoting":
> case "https-remoting": {
> return true;
> }
> default: {
> return false;
> }
> }
> }
> {code}
> and also the remote-outbound-connection does not allow that protocol:
> https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/sr...
> {code}
> public enum Protocol {
> REMOTE("remote"),
> REMOTE_HTTP("remote+http"),
> HTTP_REMOTING("http-remoting"),
> HTTPS_REMOTING("https-remoting"),
> REMOTE_HTTPS("remote+https");
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-13828) remote+tls is not supported by EJBClient and remote-outbound-connection
by Matthias Großmann (Jira)
[ https://issues.redhat.com/browse/WFLY-13828?page=com.atlassian.jira.plugi... ]
Matthias Großmann updated WFLY-13828:
-------------------------------------
Description:
Hi,
in our company we would like to use the newest Wildfly together with legacy servers like Jboss 7 over SSL.
This is possible with the Uri scheme "remote+tls" provided by jboss-remoting
https://github.com/jboss-remoting/jboss-remoting/blob/master/src/main/jav...
{code:java}
// remote (SSL is explicit in URL)
final RemoteConnectionProviderFactory remoteConnectionProviderFactory = new RemoteConnectionProviderFactory();
...
endpoint.addConnectionProvider("remote+tls", remoteConnectionProviderFactory, OptionMap.create(Options.SECURE, Boolean.TRUE));
{code}
But that uri scheme is not supported by the jboss-ejb-client in current version
https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
{code}
public boolean supportsProtocol(final String uriScheme) {
switch (uriScheme) {
case "remote":
case "remote+http":
case "remote+https":
// compatibility
case "remoting":
case "http-remoting":
case "https-remoting": {
return true;
}
default: {
return false;
}
}
}
{code}
and also the remote-outbound-connection does not allow that protocol:
https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/sr...
{code}
public enum Protocol {
REMOTE("remote"),
REMOTE_HTTP("remote+http"),
HTTP_REMOTING("http-remoting"),
HTTPS_REMOTING("https-remoting"),
REMOTE_HTTPS("remote+https");
{code}
was:
Hi,
in our company we would like to use the newest Wildfly together with legacy servers like Jboss 7 over SSL.
This is possible with the Uri scheme "remote+tls" provided by jboss-remoting
https://github.com/jboss-remoting/jboss-remoting/blob/master/src/main/jav...
{code:java}
// remote (SSL is explicit in URL)
final RemoteConnectionProviderFactory remoteConnectionProviderFactory = new RemoteConnectionProviderFactory();
endpoint.addConnectionProvider("remote", remoteConnectionProviderFactory, OptionMap.create(Options.SSL_ENABLED, Boolean.TRUE, Options.SSL_STARTTLS, Boolean.TRUE));
endpoint.addConnectionProvider("remote+tls", remoteConnectionProviderFactory, OptionMap.create(Options.SECURE, Boolean.TRUE));
// old (SSL is config-based)
endpoint.addConnectionProvider("remoting", remoteConnectionProviderFactory, OptionMap.create(Options.SSL_ENABLED, Boolean.TRUE, Options.SSL_STARTTLS, Boolean.TRUE));
// http - SSL is handled by the HTTP layer
final HttpUpgradeConnectionProviderFactory httpUpgradeConnectionProviderFactory = new HttpUpgradeConnectionProviderFactory();
endpoint.addConnectionProvider("remote+http", httpUpgradeConnectionProviderFactory, OptionMap.create(Options.SSL_ENABLED, Boolean.FALSE, Options.SSL_STARTTLS, Boolean.TRUE));
endpoint.addConnectionProvider("remote+https", httpUpgradeConnectionProviderFactory, OptionMap.create(Options.SECURE, Boolean.TRUE));
// old
endpoint.addConnectionProvider("http-remoting", httpUpgradeConnectionProviderFactory, OptionMap.create(Options.SSL_ENABLED, Boolean.FALSE, Options.SSL_STARTTLS, Boolean.TRUE));
endpoint.addConnectionProvider("https-remoting", httpUpgradeConnectionProviderFactory, OptionMap.create(Options.SECURE, Boolean.TRUE)); {code}
But that uri scheme is not supported by the jboss-ejb-client in current version
https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
{code}
public boolean supportsProtocol(final String uriScheme) {
switch (uriScheme) {
case "remote":
case "remote+http":
case "remote+https":
// compatibility
case "remoting":
case "http-remoting":
case "https-remoting": {
return true;
}
default: {
return false;
}
}
}
{code}
and also the remote-outbound-connection does not allow that protocol:
https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/sr...
{code}
public enum Protocol {
REMOTE("remote"),
REMOTE_HTTP("remote+http"),
HTTP_REMOTING("http-remoting"),
HTTPS_REMOTING("https-remoting"),
REMOTE_HTTPS("remote+https");
{code}
> remote+tls is not supported by EJBClient and remote-outbound-connection
> -----------------------------------------------------------------------
>
> Key: WFLY-13828
> URL: https://issues.redhat.com/browse/WFLY-13828
> Project: WildFly
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 20.0.1.Final
> Reporter: Matthias Großmann
> Assignee: Flavia Rainone
> Priority: Major
>
> Hi,
> in our company we would like to use the newest Wildfly together with legacy servers like Jboss 7 over SSL.
> This is possible with the Uri scheme "remote+tls" provided by jboss-remoting
> https://github.com/jboss-remoting/jboss-remoting/blob/master/src/main/jav...
> {code:java}
> // remote (SSL is explicit in URL)
>
> final RemoteConnectionProviderFactory remoteConnectionProviderFactory = new RemoteConnectionProviderFactory();
> ...
> endpoint.addConnectionProvider("remote+tls", remoteConnectionProviderFactory, OptionMap.create(Options.SECURE, Boolean.TRUE));
> {code}
> But that uri scheme is not supported by the jboss-ejb-client in current version
> https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
> {code}
> public boolean supportsProtocol(final String uriScheme) {
> switch (uriScheme) {
> case "remote":
> case "remote+http":
> case "remote+https":
> // compatibility
> case "remoting":
> case "http-remoting":
> case "https-remoting": {
> return true;
> }
> default: {
> return false;
> }
> }
> }
> {code}
> and also the remote-outbound-connection does not allow that protocol:
> https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/sr...
> {code}
> public enum Protocol {
> REMOTE("remote"),
> REMOTE_HTTP("remote+http"),
> HTTP_REMOTING("http-remoting"),
> HTTPS_REMOTING("https-remoting"),
> REMOTE_HTTPS("remote+https");
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-13828) remote+tls is not supported by EJBClient and remote-outbound-connection
by Matthias Großmann (Jira)
Matthias Großmann created WFLY-13828:
----------------------------------------
Summary: remote+tls is not supported by EJBClient and remote-outbound-connection
Key: WFLY-13828
URL: https://issues.redhat.com/browse/WFLY-13828
Project: WildFly
Issue Type: Bug
Components: Remoting
Affects Versions: 20.0.1.Final
Reporter: Matthias Großmann
Assignee: Flavia Rainone
Hi,
in our company we would like to use the newest Wildfly together with legacy servers like Jboss 7 over SSL.
This is possible with the Uri scheme "remote+tls" provided by jboss-remoting
https://github.com/jboss-remoting/jboss-remoting/blob/master/src/main/jav...
{code:java}
// remote (SSL is explicit in URL)
final RemoteConnectionProviderFactory remoteConnectionProviderFactory = new RemoteConnectionProviderFactory();
endpoint.addConnectionProvider("remote", remoteConnectionProviderFactory, OptionMap.create(Options.SSL_ENABLED, Boolean.TRUE, Options.SSL_STARTTLS, Boolean.TRUE));
endpoint.addConnectionProvider("remote+tls", remoteConnectionProviderFactory, OptionMap.create(Options.SECURE, Boolean.TRUE));
// old (SSL is config-based)
endpoint.addConnectionProvider("remoting", remoteConnectionProviderFactory, OptionMap.create(Options.SSL_ENABLED, Boolean.TRUE, Options.SSL_STARTTLS, Boolean.TRUE));
// http - SSL is handled by the HTTP layer
final HttpUpgradeConnectionProviderFactory httpUpgradeConnectionProviderFactory = new HttpUpgradeConnectionProviderFactory();
endpoint.addConnectionProvider("remote+http", httpUpgradeConnectionProviderFactory, OptionMap.create(Options.SSL_ENABLED, Boolean.FALSE, Options.SSL_STARTTLS, Boolean.TRUE));
endpoint.addConnectionProvider("remote+https", httpUpgradeConnectionProviderFactory, OptionMap.create(Options.SECURE, Boolean.TRUE));
// old
endpoint.addConnectionProvider("http-remoting", httpUpgradeConnectionProviderFactory, OptionMap.create(Options.SSL_ENABLED, Boolean.FALSE, Options.SSL_STARTTLS, Boolean.TRUE));
endpoint.addConnectionProvider("https-remoting", httpUpgradeConnectionProviderFactory, OptionMap.create(Options.SECURE, Boolean.TRUE)); {code}
But that uri scheme is not supported by the jboss-ejb-client in current version
https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
{code}
public boolean supportsProtocol(final String uriScheme) {
switch (uriScheme) {
case "remote":
case "remote+http":
case "remote+https":
// compatibility
case "remoting":
case "http-remoting":
case "https-remoting": {
return true;
}
default: {
return false;
}
}
}
{code}
and also the remote-outbound-connection does not allow that protocol:
https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/sr...
{code}
public enum Protocol {
REMOTE("remote"),
REMOTE_HTTP("remote+http"),
HTTP_REMOTING("http-remoting"),
HTTPS_REMOTING("https-remoting"),
REMOTE_HTTPS("remote+https");
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (DROOLS-5631) Rule evaluation optimization
by Toshiya Kobayashi (Jira)
Toshiya Kobayashi created DROOLS-5631:
-----------------------------------------
Summary: Rule evaluation optimization
Key: DROOLS-5631
URL: https://issues.redhat.com/browse/DROOLS-5631
Project: Drools
Issue Type: Story
Components: core engine
Affects Versions: 7.42.0.Final
Reporter: Toshiya Kobayashi
Assignee: Toshiya Kobayashi
Motivation: This Story aims at rule evaluation optimization so both Kogito and drools core engine usage will get benefits for overall rule execution. It contains Alpha Node Ordering to maximize sharing and minimize the number of evaluations, Range Indexing (may add more).
Goals: Better rule execution performance. For each improvement, add benchmark and measure the performance gain.
Impact: Better rule execution performance. It might have overhead during rule build time. Will confirm with benchmark anyway.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (DROOLS-5617) Refactor MiningModel source generation
by Gabriele Cardosi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5617?page=com.atlassian.jira.plug... ]
Gabriele Cardosi updated DROOLS-5617:
-------------------------------------
Summary: Refactor MiningModel source generation (was: Refacto MiningModel source generation)
> Refactor MiningModel source generation
> --------------------------------------
>
> Key: DROOLS-5617
> URL: https://issues.redhat.com/browse/DROOLS-5617
> Project: Drools
> Issue Type: Task
> Reporter: Gabriele Cardosi
> Assignee: Gabriele Cardosi
> Priority: Blocker
> Labels: TrustyAI
>
> For code generation, currently, all sources of segment models of a MiningModel are put in the main (container) model sourcemap, and the list of "nested models" is empty.
> Scope of this refactor is to populate the list of nested models with the "HasSourcesMap" version of all the models, and populate the "main" sourcemap only with the MiningModel specific sources
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months