[JBoss JIRA] (WFLY-10643) Remove the *-licenses-addendum.html files
by Kabir Khan (JIRA)
Kabir Khan created WFLY-10643:
---------------------------------
Summary: Remove the *-licenses-addendum.html files
Key: WFLY-10643
URL: https://issues.jboss.org/browse/WFLY-10643
Project: WildFly
Issue Type: Task
Components: Build System
Reporter: Kabir Khan
Assignee: Kabir Khan
Priority: Critical
These *-addendum.html files contain licenses for modules brought in for the dual EE8/EE7 support. Once we've removed this support, we should remove these files.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 3 months
[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:
--------------------------------
Results with {{min_interval=5000}} and {{max_interval=10000}}:
{noformat}
Results for TCP
Min merge time=16031
Max merge time=16091
Avg merge time=16057.0
===================================================================
Results for UDP
Min merge time=16022
Max merge time=16107
Avg merge time=16055.0
===================================================================
{noformat}
> 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)
7 years, 3 months
[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 commented on WFLY-10640:
--------------------------------
[~maeste] Do you see any problem if only valid +javax.sql.DataSource+ / +javax.sql.XADataSource+ implementation can be specified when updating the JDBC driver or adding the datasource? For now, I can see that the smoke test [DataSourceOperationsUnitTestCase#testAddXaDsWithProperties|https://github...] will fail.
> 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)
7 years, 3 months
[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)
7 years, 3 months
[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)
7 years, 3 months
[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)
7 years, 3 months
[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)
7 years, 3 months
[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)
7 years, 3 months
[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)
7 years, 3 months
[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)
7 years, 3 months