[JBoss JIRA] (DROOLS-2655) [DMN Designer]: Decision Table: Automatically create input columns for each InputData element
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2655?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-2655:
----------------------------------------
[~jomarko] For the sake of remaining "agile" I'd propose this JIRA adds input columns for all {{InputData}} elements and if we'd later prefer to provide the User with the ability to select the elements for which they'd want columns created we open a new JIRA to further enhance the feature.
> [DMN Designer]: Decision Table: Automatically create input columns for each InputData element
> ---------------------------------------------------------------------------------------------
>
> Key: DROOLS-2655
> URL: https://issues.jboss.org/browse/DROOLS-2655
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Affects Versions: 7.8.0.Final
> Reporter: Michael Anstis
> Assignee: Michael Anstis
>
> [~tari_manga] suggested it advantageous to create input columns for each {{InputData}} element linked to the {{Decision}}/{{BusinessKnowledgeModel}} containing the {{DecisionTable}} expression. For example, if a BKM has 2 {{InputData}} nodes of simple data-types then two columns should be created. If a BKM has 1 {{InputData}} node of complex data-type that consists of 3 elements then 3 columns should be created.
> - For simple data types the input column names should correspond exactly to InputData elements.
> - For complex data types, we should use dot notation, e.g. Person.name, Person.salary ...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (JGRP-2281) MERGE3 blocks unnecessarily in discovery when non-multicast transport is used
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2281?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2281:
--------------------------------
Both UDP and TCP now use the same time to merge the 10 members back into a single cluster.
> MERGE3 blocks unnecessarily in discovery when non-multicast transport is used
> -----------------------------------------------------------------------------
>
> Key: JGRP-2281
> URL: https://issues.jboss.org/browse/JGRP-2281
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.13
>
>
> When MERGE3 uses TCP, it cannot multicast its INFO message, and therefore uses the discovery protocol (e.g. MPING) to fetch the targets to send the INFO message to.
> Since we don't know how many responses to expect, we simply block for {{(min_interval + max_interval /2) ms}}. This is bad, as it delays the sending of INFO messages, which results in a partial merge as we're likely not to get responses from *all* members. This delays a full merge, e.g. when we have many singleton subclusters. A heavily split cluster will therefore likely require more merge rounds than necessary when using TCP, compared to (e.g.) UDP.
> h4. Solution:
> * The discovery process should be _reactive_ rather than blocking: instead of waiting for N seconds, we simply pass a function to the discovery protocol that gets invoked whenever a response has been received
> * When the function gets invoked, it sends an INFO to the respective member
> * This prevents 1 thread from blocking for N seconds
> See \[1\] for details.
> \[1\] https://github.com/belaban/JGroups/pull/389
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (JGRP-2281) MERGE3 blocks unnecessarily in discovery when non-multicast transport is used
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2281?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2281.
----------------------------
Resolution: Done
> MERGE3 blocks unnecessarily in discovery when non-multicast transport is used
> -----------------------------------------------------------------------------
>
> Key: JGRP-2281
> URL: https://issues.jboss.org/browse/JGRP-2281
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.13
>
>
> When MERGE3 uses TCP, it cannot multicast its INFO message, and therefore uses the discovery protocol (e.g. MPING) to fetch the targets to send the INFO message to.
> Since we don't know how many responses to expect, we simply block for {{(min_interval + max_interval /2) ms}}. This is bad, as it delays the sending of INFO messages, which results in a partial merge as we're likely not to get responses from *all* members. This delays a full merge, e.g. when we have many singleton subclusters. A heavily split cluster will therefore likely require more merge rounds than necessary when using TCP, compared to (e.g.) UDP.
> h4. Solution:
> * The discovery process should be _reactive_ rather than blocking: instead of waiting for N seconds, we simply pass a function to the discovery protocol that gets invoked whenever a response has been received
> * When the function gets invoked, it sends an INFO to the respective member
> * This prevents 1 thread from blocking for N seconds
> See \[1\] for details.
> \[1\] https://github.com/belaban/JGroups/pull/389
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10640) driver-datasource-class-name and driver-xa-datasource-class-name need to be validated when updating
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFLY-10640?page=com.atlassian.jira.plugin... ]
Lin Gao updated WFLY-10640:
---------------------------
Description:
Download oracle jdbc driver at http://www.oracle.com/technetwork/database/features/jdbc/jdbc-ucp-122-311...
Install the driver as a module and add the JDBC driver:
{code:bash}
module add --name=com.oracle.jdbc --resources=/opt/Downloads/ojdbc8.jar --dependencies=[javax.api, javax.transaction.api]
/subsystem=datasources/jdbc-driver=oracle:add(driver-name=oracle, driver-module-name=com.oracle.jdbc, driver-datasource-class-name=oracle.jdbc.datasource.OracleDataSource, driver-xa-datasource-class-name=oracle.jdbc.xa.client.OracleXADataSource, driver-class-name=oracle.jdbc.OracleDriver)
{code}
It should fail because the configuraiton:
{code:java}
driver-datasource-class-name=oracle.jdbc.datasource.OracleDataSource
{code}
is wrong, +oracle.jdbc.datasource.OracleDataSource+ is an interface, not a concrete class.
It should be the same for the data-source creation when specifying the datasource-class.
was:
Download oracle jdbc driver at http://www.oracle.com/technetwork/database/features/jdbc/jdbc-ucp-122-311...
Install the driver as a module and add the JDBC driver:
{code:bash}
module add --name=com.oracle.jdbc --resources=/opt/Downloads/ojdbc8.jar --dependencies=[javax.api, javax.transaction.api]
/subsystem=datasources/jdbc-driver=oracle:add(driver-name=oracle, driver-module-name=com.oracle.jdbc, driver-datasource-class-name=oracle.jdbc.datasource.OracleDataSource, driver-xa-datasource-class-name=oracle.jdbc.xa.client.OracleXADataSource, driver-class-name=oracle.jdbc.OracleDriver)
{code}
It should fail because the configuraiton:
{code:java}
driver-datasource-class-name=oracle.jdbc.datasource.OracleDataSource
{code}
is wrong, +oracle.jdbc.datasource.OracleDataSource+ is an interface, not a concrete class.
> driver-datasource-class-name and driver-xa-datasource-class-name need to be validated when updating
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-10640
> URL: https://issues.jboss.org/browse/WFLY-10640
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Reporter: Lin Gao
> Assignee: Lin Gao
> Priority: Minor
>
> Download oracle jdbc driver at http://www.oracle.com/technetwork/database/features/jdbc/jdbc-ucp-122-311...
> Install the driver as a module and add the JDBC driver:
> {code:bash}
> module add --name=com.oracle.jdbc --resources=/opt/Downloads/ojdbc8.jar --dependencies=[javax.api, javax.transaction.api]
> /subsystem=datasources/jdbc-driver=oracle:add(driver-name=oracle, driver-module-name=com.oracle.jdbc, driver-datasource-class-name=oracle.jdbc.datasource.OracleDataSource, driver-xa-datasource-class-name=oracle.jdbc.xa.client.OracleXADataSource, driver-class-name=oracle.jdbc.OracleDriver)
> {code}
> It should fail because the configuraiton:
> {code:java}
> driver-datasource-class-name=oracle.jdbc.datasource.OracleDataSource
> {code}
> is wrong, +oracle.jdbc.datasource.OracleDataSource+ is an interface, not a concrete class.
> It should be the same for the data-source creation when specifying the datasource-class.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (JGRP-2281) MERGE3 blocks unnecessarily in discovery when non-multicast transport is used
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2281?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2281:
--------------------------------
New event {{FIND_MBRS_ASYNC}} was created with arg {{Consmer<PingData>}}. The arg is a callback that's invoked whenever a discovery response is received
> MERGE3 blocks unnecessarily in discovery when non-multicast transport is used
> -----------------------------------------------------------------------------
>
> Key: JGRP-2281
> URL: https://issues.jboss.org/browse/JGRP-2281
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.13
>
>
> When MERGE3 uses TCP, it cannot multicast its INFO message, and therefore uses the discovery protocol (e.g. MPING) to fetch the targets to send the INFO message to.
> Since we don't know how many responses to expect, we simply block for {{(min_interval + max_interval /2) ms}}. This is bad, as it delays the sending of INFO messages, which results in a partial merge as we're likely not to get responses from *all* members. This delays a full merge, e.g. when we have many singleton subclusters. A heavily split cluster will therefore likely require more merge rounds than necessary when using TCP, compared to (e.g.) UDP.
> h4. Solution:
> * The discovery process should be _reactive_ rather than blocking: instead of waiting for N seconds, we simply pass a function to the discovery protocol that gets invoked whenever a response has been received
> * When the function gets invoked, it sends an INFO to the respective member
> * This prevents 1 thread from blocking for N seconds
> See \[1\] for details.
> \[1\] https://github.com/belaban/JGroups/pull/389
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (JGRP-2281) MERGE3 blocks unnecessarily in discovery when non-multicast transport is used
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2281?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2281 at 6/27/18 4:54 AM:
---------------------------------------------------------
New event {{FIND_MBRS_ASYNC}} was created with arg {{Consumer<PingData>}}. The arg is a callback that's invoked whenever a discovery response is received
was (Author: belaban):
New event {{FIND_MBRS_ASYNC}} was created with arg {{Consmer<PingData>}}. The arg is a callback that's invoked whenever a discovery response is received
> MERGE3 blocks unnecessarily in discovery when non-multicast transport is used
> -----------------------------------------------------------------------------
>
> Key: JGRP-2281
> URL: https://issues.jboss.org/browse/JGRP-2281
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.13
>
>
> When MERGE3 uses TCP, it cannot multicast its INFO message, and therefore uses the discovery protocol (e.g. MPING) to fetch the targets to send the INFO message to.
> Since we don't know how many responses to expect, we simply block for {{(min_interval + max_interval /2) ms}}. This is bad, as it delays the sending of INFO messages, which results in a partial merge as we're likely not to get responses from *all* members. This delays a full merge, e.g. when we have many singleton subclusters. A heavily split cluster will therefore likely require more merge rounds than necessary when using TCP, compared to (e.g.) UDP.
> h4. Solution:
> * The discovery process should be _reactive_ rather than blocking: instead of waiting for N seconds, we simply pass a function to the discovery protocol that gets invoked whenever a response has been received
> * When the function gets invoked, it sends an INFO to the respective member
> * This prevents 1 thread from blocking for N seconds
> See \[1\] for details.
> \[1\] https://github.com/belaban/JGroups/pull/389
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (JGRP-2281) MERGE3 blocks unnecessarily in discovery when non-multicast transport is used
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2281?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2281:
---------------------------
Comment: was deleted
(was: Looks like {{Event.FIND_MBRS}} can be changed directly rather than creating a new event, as this is only used by {{MERGE3}} and {{TP}}, and both can be changed to become reactive.)
> MERGE3 blocks unnecessarily in discovery when non-multicast transport is used
> -----------------------------------------------------------------------------
>
> Key: JGRP-2281
> URL: https://issues.jboss.org/browse/JGRP-2281
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.13
>
>
> When MERGE3 uses TCP, it cannot multicast its INFO message, and therefore uses the discovery protocol (e.g. MPING) to fetch the targets to send the INFO message to.
> Since we don't know how many responses to expect, we simply block for {{(min_interval + max_interval /2) ms}}. This is bad, as it delays the sending of INFO messages, which results in a partial merge as we're likely not to get responses from *all* members. This delays a full merge, e.g. when we have many singleton subclusters. A heavily split cluster will therefore likely require more merge rounds than necessary when using TCP, compared to (e.g.) UDP.
> h4. Solution:
> * The discovery process should be _reactive_ rather than blocking: instead of waiting for N seconds, we simply pass a function to the discovery protocol that gets invoked whenever a response has been received
> * When the function gets invoked, it sends an INFO to the respective member
> * This prevents 1 thread from blocking for N seconds
> See \[1\] for details.
> \[1\] https://github.com/belaban/JGroups/pull/389
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10619) Add version 7 of the management model for the Undertow subsystem
by Jan Stourac (JIRA)
[ https://issues.jboss.org/browse/WFLY-10619?page=com.atlassian.jira.plugin... ]
Jan Stourac commented on WFLY-10619:
------------------------------------
[~dlofthouse], [~kabirkhan] Just a curious question - I can see that new undertow model of version 7 has no difference when compared to version 6. What is actual reason for adding this? Is it just in advance change because of the planned changes? Normally I would expect that new model is introduced when there are some real changes in model so we avoid unnecessary version increments.
> Add version 7 of the management model for the Undertow subsystem
> ----------------------------------------------------------------
>
> Key: WFLY-10619
> URL: https://issues.jboss.org/browse/WFLY-10619
> Project: WildFly
> Issue Type: Task
> Components: Web (Undertow)
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 14.0.0.CR1
>
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (JGRP-2281) MERGE3 blocks unnecessarily in discovery when non-multicast transport is used
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2281?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2281:
---------------------------
Description:
When MERGE3 uses TCP, it cannot multicast its INFO message, and therefore uses the discovery protocol (e.g. MPING) to fetch the targets to send the INFO message to.
Since we don't know how many responses to expect, we simply block for {{(min_interval + max_interval /2) ms}}. This is bad, as it delays the sending of INFO messages, which results in a partial merge as we're likely not to get responses from *all* members. This delays a full merge, e.g. when we have many singleton subclusters. A heavily split cluster will therefore likely require more merge rounds than necessary when using TCP, compared to (e.g.) UDP.
h4. Solution:
* The discovery process should be _reactive_ rather than blocking: instead of waiting for N seconds, we simply pass a function to the discovery protocol that gets invoked whenever a response has been received
* When the function gets invoked, it sends an INFO to the respective member
* This prevents 1 thread from blocking for N seconds
See \[1\] for details.
\[1\] https://github.com/belaban/JGroups/pull/389
was:
When MERGE3 uses TCP, it cannot multicast its INFO message, and therefore uses the discovery protocol (e.g. MPING) to fetch the targets to send the INFO message to.
Since we don't know how many responses to expect, we simply block for {{(min_interval + max_interval /2) ms}}. This is bad, as it delays the sending of INFO messages, which results in a partial merge as we're likely not to get responses from *all* members. This delays a full merge, e.g. when we have many singleton subclusters. A heavily split cluster will therefore likely require more merge rounds than necessary when using TCP, compared to (e.g.) UDP.
h4. Solution:
* The discovery process should be _reactive_ rather than blocking: instead of waiting for N seconds, we simply pass a function to the discovery protocol that gets invoked whenever a response has been received
* When the function gets invoked, it sends an INFO to the respective member
* This prevents up 1 thread from blocking for N seconds
See \[1\] for details.
\[1\] https://github.com/belaban/JGroups/pull/389
> MERGE3 blocks unnecessarily in discovery when non-multicast transport is used
> -----------------------------------------------------------------------------
>
> Key: JGRP-2281
> URL: https://issues.jboss.org/browse/JGRP-2281
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.13
>
>
> When MERGE3 uses TCP, it cannot multicast its INFO message, and therefore uses the discovery protocol (e.g. MPING) to fetch the targets to send the INFO message to.
> Since we don't know how many responses to expect, we simply block for {{(min_interval + max_interval /2) ms}}. This is bad, as it delays the sending of INFO messages, which results in a partial merge as we're likely not to get responses from *all* members. This delays a full merge, e.g. when we have many singleton subclusters. A heavily split cluster will therefore likely require more merge rounds than necessary when using TCP, compared to (e.g.) UDP.
> h4. Solution:
> * The discovery process should be _reactive_ rather than blocking: instead of waiting for N seconds, we simply pass a function to the discovery protocol that gets invoked whenever a response has been received
> * When the function gets invoked, it sends an INFO to the respective member
> * This prevents 1 thread from blocking for N seconds
> See \[1\] for details.
> \[1\] https://github.com/belaban/JGroups/pull/389
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years