[JBoss JIRA] (JGRP-1957) S3_PING: Nodes never removed from .list file
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1957?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1957:
---------------------------
Fix Version/s: 3.6.5
> S3_PING: Nodes never removed from .list file
> --------------------------------------------
>
> Key: JGRP-1957
> URL: https://issues.jboss.org/browse/JGRP-1957
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.4
> Environment: JGroups client running on Mac OS X - Yosemite
> JDK 1.7.71
> Reporter: Nick Sawadsky
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.5
>
>
> I'm not 100% sure, but it seems like there might be a defect here.
> I'm using TCP, S3_PING, and MERGE3.
> I've set logical_addr_cache_max_size to 2 for testing purposes, although I don't think the value of this setting affects my test results.
> I start a single node, node A. Then I start a second node, node B.
> I then repeatedly shutdown and restart node B.
> Each time node B starts, a new row is added to the .list file stored in S3.
> But even if I continue this process for 15 minutes, old rows are never removed from the .list file, so it continues to grow in size.
> I've read the docs and mailing list threads, so I'm aware that the list is not immediately updated as soon as a member leaves. But I was expecting that when a view change occurs, nodes no longer in the view would be marked for removal (line 2193 of TP.java) and then after the logical_addr_cache_expiration has been reached and the reaper kicks in, once a new node joins, the expired cache entries would be purged from the file.
> I dug in to the code a bit, and what seems to be happening is that the MERGE3 protocol periodically generates a FIND_MBRS event. S3_PING retrieves the membership from the .list file, which includes expired nodes. And then all of these members are re-added to the logical address cache (line 157 of S3_PING.java, line 533 of Discovery.java, line 2263 of TP.java).
> So expired nodes are continually re-added to the logical address cache, preventing them from ever being reaped.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (WFLY-5199) On MariaDB 5.3+ and MySQL 5.6.4+, EJB timers in a JDBC storage don't work correctly due to timestamp rounding
by Jan Martiska (JIRA)
[ https://issues.jboss.org/browse/WFLY-5199?page=com.atlassian.jira.plugin.... ]
Jan Martiska updated WFLY-5199:
-------------------------------
Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/7998)
> On MariaDB 5.3+ and MySQL 5.6.4+, EJB timers in a JDBC storage don't work correctly due to timestamp rounding
> -------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5199
> URL: https://issues.jboss.org/browse/WFLY-5199
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Beta2
> Environment: MariaDB 5.3+, Mysql 5.6.4+
> Reporter: Jan Martiska
> Assignee: Stuart Douglas
> Fix For: 10.0.0.CR1
>
>
> EJB timers don't execute, because the DatabaseTimerPersistence.shouldRun method returns false for them, because it is unable to SELECT them from the database using a java.sql.Timestamp.
> On MariaDB 5.3+ and MySQL 5.6.4+, the behavior of the DATETIME type has changed compared to MySQL 5.5 and older.
> In previous versions, it was possible to insert into DATETIME columns with JDBC using a java.sql.Timestamp which contained fractional seconds, the fraction was truncated/rounded and a subsequent SELECT statement with the same java.sql.Timestamp returned such rows, because the fraction was truncated/rounded from the queried Timestamp too.
> On MySQL 5.6.4+ and MariaDB 5.3+, when a java.sql.Timestamp including a fractional second is inserted into a DATETIME, attempting to SELECT with the same Timestamp doesn't return the row, because the DATETIME type now defaults to DATETIME(0) which truncates/rounds to whole seconds, and the queried Timestamp no longer gets truncated/rounded during the query execution. It would only work if the column was declared as DATETIME(6), which ensures that inserted values don't get truncated/rounded. Documentation: https://dev.mysql.com/doc/refman/5.7/en/fractional-seconds.html
> MySQL rounds the timestamp, MariaDB truncates it (always rounds down).
> However, declaring DATETIME(6) is not possible in older versions of MySQL or MariaDB, so to support both new and old versions, we have probably these options:
> 1. introduce a new DDL file(s) for MySQL 5.6.4+ and MariaDB 5.3+ and use it depending on the detected version - this DDL would use DATETIME(6) instead of DATETIME
> 2. change the DatabaseTimerPersistence implementation so that it will not insert fractional seconds into the database at all (EJB timers don't support timing with higher precision than whole seconds anyway)
> 3. same as option 2, but only for MariaDB/MySQL dialects
> 4. any other idea?
> I personally like number 3 the best, it is the least risky and introduces only minimal changes.. but it's still somewhat ugly.
> This seems to resolve it for me (implementation suggestion of option 3): https://github.com/jmartisk/wildfly/commits/mysql-mariadb-timer-suggestion
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (WFLY-5199) On MariaDB 5.3+ and MySQL 5.6.4+, EJB timers in a JDBC storage don't work correctly due to timestamp rounding
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5199?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-5199:
--------------------------------------
Sorry, my bad, I did not pay enough attention.
I think 3) is fine, can you send in a PR?
> On MariaDB 5.3+ and MySQL 5.6.4+, EJB timers in a JDBC storage don't work correctly due to timestamp rounding
> -------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5199
> URL: https://issues.jboss.org/browse/WFLY-5199
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Beta2
> Environment: MariaDB 5.3+, Mysql 5.6.4+
> Reporter: Jan Martiska
> Assignee: Stuart Douglas
> Fix For: 10.0.0.CR1
>
>
> EJB timers don't execute, because the DatabaseTimerPersistence.shouldRun method returns false for them, because it is unable to SELECT them from the database using a java.sql.Timestamp.
> On MariaDB 5.3+ and MySQL 5.6.4+, the behavior of the DATETIME type has changed compared to MySQL 5.5 and older.
> In previous versions, it was possible to insert into DATETIME columns with JDBC using a java.sql.Timestamp which contained fractional seconds, the fraction was truncated/rounded and a subsequent SELECT statement with the same java.sql.Timestamp returned such rows, because the fraction was truncated/rounded from the queried Timestamp too.
> On MySQL 5.6.4+ and MariaDB 5.3+, when a java.sql.Timestamp including a fractional second is inserted into a DATETIME, attempting to SELECT with the same Timestamp doesn't return the row, because the DATETIME type now defaults to DATETIME(0) which truncates/rounds to whole seconds, and the queried Timestamp no longer gets truncated/rounded during the query execution. It would only work if the column was declared as DATETIME(6), which ensures that inserted values don't get truncated/rounded. Documentation: https://dev.mysql.com/doc/refman/5.7/en/fractional-seconds.html
> MySQL rounds the timestamp, MariaDB truncates it (always rounds down).
> However, declaring DATETIME(6) is not possible in older versions of MySQL or MariaDB, so to support both new and old versions, we have probably these options:
> 1. introduce a new DDL file(s) for MySQL 5.6.4+ and MariaDB 5.3+ and use it depending on the detected version - this DDL would use DATETIME(6) instead of DATETIME
> 2. change the DatabaseTimerPersistence implementation so that it will not insert fractional seconds into the database at all (EJB timers don't support timing with higher precision than whole seconds anyway)
> 3. same as option 2, but only for MariaDB/MySQL dialects
> 4. any other idea?
> I personally like number 3 the best, it is the least risky and introduces only minimal changes.. but it's still somewhat ugly.
> This seems to resolve it for me (implementation suggestion of option 3): https://github.com/jmartisk/wildfly/commits/mysql-mariadb-timer-suggestion
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (WFLY-5242) Inconsistent format for IPv6 addresses in server log
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5242?page=com.atlassian.jira.plugin.... ]
Stuart Douglas updated WFLY-5242:
---------------------------------
Priority: Minor (was: Major)
> Inconsistent format for IPv6 addresses in server log
> ----------------------------------------------------
>
> Key: WFLY-5242
> URL: https://issues.jboss.org/browse/WFLY-5242
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Beta2
> Reporter: Lyle Wang
> Assignee: Stuart Douglas
> Priority: Minor
>
> Description of problem:
> When IPv6 is used, square brackets for IPv6 addresses are missed in some of log entries. Specifically, the address format from Undertow logs is different from those "WFLYSRV" logs.
> How reproducible:
> Always
> Steps to Reproduce:
> 1. Config IPv6 (example: https://docs.jboss.org/author/display/WFLY10/Interfaces+and+ports)
> 2. Start WildFly and check the log
> Actual results:
> ----------------------------------------
> 2015-08-31 12:51:47,812 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0006: Undertow HTTP listener default listening on /0:0:0:0:0:0:0:1:8080
> ......
> 2015-08-31 12:51:48,431 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[::1]:9993/management
> 2015-08-31 12:51:48,432 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[::1]:9993
> ----------------------------------------
> In Undertow logs it's like "/0:0:0:0:0:0:0:1:8080" but in WildFly server logs "http://[::1]:9993/management"
> Expected results:
> Consistent format should be used for IPv6 address across different components and the address is enclosed in square brackets [ ].
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (WFLY-5242) Inconsistent format for IPv6 addresses in server log
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-5242?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-5242:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1258298
Bugzilla Update: Perform
> Inconsistent format for IPv6 addresses in server log
> ----------------------------------------------------
>
> Key: WFLY-5242
> URL: https://issues.jboss.org/browse/WFLY-5242
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Beta2
> Reporter: Lyle Wang
> Assignee: Stuart Douglas
>
> Description of problem:
> When IPv6 is used, square brackets for IPv6 addresses are missed in some of log entries. Specifically, the address format from Undertow logs is different from those "WFLYSRV" logs.
> How reproducible:
> Always
> Steps to Reproduce:
> 1. Config IPv6 (example: https://docs.jboss.org/author/display/WFLY10/Interfaces+and+ports)
> 2. Start WildFly and check the log
> Actual results:
> ----------------------------------------
> 2015-08-31 12:51:47,812 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0006: Undertow HTTP listener default listening on /0:0:0:0:0:0:0:1:8080
> ......
> 2015-08-31 12:51:48,431 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[::1]:9993/management
> 2015-08-31 12:51:48,432 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[::1]:9993
> ----------------------------------------
> In Undertow logs it's like "/0:0:0:0:0:0:0:1:8080" but in WildFly server logs "http://[::1]:9993/management"
> Expected results:
> Consistent format should be used for IPv6 address across different components and the address is enclosed in square brackets [ ].
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (WFLY-5242) Inconsistent format for IPv6 addresses in server log
by Lyle Wang (JIRA)
Lyle Wang created WFLY-5242:
-------------------------------
Summary: Inconsistent format for IPv6 addresses in server log
Key: WFLY-5242
URL: https://issues.jboss.org/browse/WFLY-5242
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 10.0.0.Beta2
Reporter: Lyle Wang
Assignee: Stuart Douglas
Description of problem:
When IPv6 is used, square brackets for IPv6 addresses are missed in some of log entries. Specifically, the address format from Undertow logs is different from those "WFLYSRV" logs.
How reproducible:
Always
Steps to Reproduce:
1. Config IPv6 (example: https://docs.jboss.org/author/display/WFLY10/Interfaces+and+ports)
2. Start WildFly and check the log
Actual results:
----------------------------------------
2015-08-31 12:51:47,812 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0006: Undertow HTTP listener default listening on /0:0:0:0:0:0:0:1:8080
......
2015-08-31 12:51:48,431 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[::1]:9993/management
2015-08-31 12:51:48,432 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[::1]:9993
----------------------------------------
In Undertow logs it's like "/0:0:0:0:0:0:0:1:8080" but in WildFly server logs "http://[::1]:9993/management"
Expected results:
Consistent format should be used for IPv6 address across different components and the address is enclosed in square brackets [ ].
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (DROOLS-880) Return a success response but the rule seems to be not running.
by 재우 이 (JIRA)
[ https://issues.jboss.org/browse/DROOLS-880?page=com.atlassian.jira.plugin... ]
재우 이 commented on DROOLS-880:
-----------------------------
Sorry, I'm late.
I think my environment is right.
http://localhost:8080/kie-server-6.3.0.CR1-ee7/services/rest/server/conta...
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<response type="SUCCESS" msg="List of created containers">
<kie-containers>
<kie-container container-id="window" status="STARTED">
<release-id>
<artifact-id>window</artifact-id>
<group-id>infosec</group-id>
<version>1.3.3</version>
</release-id>
<resolved-release-id>
<artifact-id>window</artifact-id>
<group-id>infosec</group-id>
<version>1.3.3</version>
</resolved-release-id>
<scanner status="DISPOSED"/>
</kie-container>
</kie-containers>
</response>
> Return a success response but the rule seems to be not running.
> ---------------------------------------------------------------
>
> Key: DROOLS-880
> URL: https://issues.jboss.org/browse/DROOLS-880
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.3.0.CR1
> Environment: CPU : Intel(R) Xeon(R) CPU E5-2650
> RAM : 128Gb
> Linux Kernel : 2.6.32-431.el6.x86_64
> Drools : 6.3.0.CR1
> Rest Client : Soap UI
> Reporter: 재우 이
> Assignee: Edson Tirelli
> Attachments: 2015_08_20_11_27_43_987.mp4, window-1.1.4.jar
>
>
> Kie_server returns a success rest response status code, but nothing show up in my log file.
> It seems to be not running only in "6.3.0.CR1". (The rules work "6.2.0.Final")
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (JGRP-1957) S3_PING: Nodes never removed from .list file
by Nick Sawadsky (JIRA)
[ https://issues.jboss.org/browse/JGRP-1957?page=com.atlassian.jira.plugin.... ]
Nick Sawadsky updated JGRP-1957:
--------------------------------
Description:
I'm not 100% sure, but it seems like there might be a defect here.
I'm using TCP, S3_PING, and MERGE3.
I've set logical_addr_cache_max_size to 2 for testing purposes, although I don't think the value of this setting affects my test results.
I start a single node, node A. Then I start a second node, node B.
I then repeatedly shutdown and restart node B.
Each time node B starts, a new row is added to the .list file stored in S3.
But even if I continue this process for 15 minutes, old rows are never removed from the .list file, so it continues to grow in size.
I've read the docs and mailing list threads, so I'm aware that the list is not immediately updated as soon as a member leaves. But I was expecting that when a view change occurs, nodes no longer in the view would be marked for removal (line 2193 of TP.java) and then after the logical_addr_cache_expiration has been reached and the reaper kicks in, once a new node joins, the expired cache entries would be purged from the file.
I dug in to the code a bit, and what seems to be happening is that the MERGE3 protocol periodically generates a FIND_MBRS event. S3_PING retrieves the membership from the .list file, which includes expired nodes. And then all of these members are re-added to the logical address cache (line 157 of S3_PING.java, line 533 of Discovery.java, line 2263 of TP.java).
So expired nodes are continually re-added to the logical address cache, preventing them from ever being reaped.
was:
I'm not 100% sure, but it seems like there might be a defect here.
I'm using TCP, S3_PING, and MERGE3.
I've set logical_addr_cache_max_size to 2 for testing purposes, although I don't think the value of this setting affects my test results.
I start a single node, node A. Then I start a second node, node B.
I then repeatedly shutdown and restart node B.
Each time node B starts, a new row is added to the .list file stored in S3.
But even if I continue this process for 15 minutes, old rows are never removed from the .list file, so it continues to grow in size.
I've read the docs and mailing list threads, so I'm aware that the list is not immediately updated as soon as a member leaves. But I was expecting that when a view change occurs, nodes no longer in the view would be marked for removal (line 2193 of TP.java) and then after the logical_addr_cache_expiration has been reached and the reaper kicks in, once a new node joins, the expired cache entries would be purged from the file.
I dug in to the code a bit, and what seems to be happening is that the MERGE3 protocol periodically generates a FIND_MBRS event. S3_PING retrieves the membership from the .list file, which includes expired nodes. And then all of these members are re-added to the logical address cache (line 157 of S3_PING.java, line 533 of Discovery.java, line 2263 if TP.java).
So expired nodes are continually re-added to the logical address cache, preventing them from ever being reaped.
> S3_PING: Nodes never removed from .list file
> --------------------------------------------
>
> Key: JGRP-1957
> URL: https://issues.jboss.org/browse/JGRP-1957
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.4
> Environment: JGroups client running on Mac OS X - Yosemite
> JDK 1.7.71
> Reporter: Nick Sawadsky
> Assignee: Bela Ban
> Priority: Minor
>
> I'm not 100% sure, but it seems like there might be a defect here.
> I'm using TCP, S3_PING, and MERGE3.
> I've set logical_addr_cache_max_size to 2 for testing purposes, although I don't think the value of this setting affects my test results.
> I start a single node, node A. Then I start a second node, node B.
> I then repeatedly shutdown and restart node B.
> Each time node B starts, a new row is added to the .list file stored in S3.
> But even if I continue this process for 15 minutes, old rows are never removed from the .list file, so it continues to grow in size.
> I've read the docs and mailing list threads, so I'm aware that the list is not immediately updated as soon as a member leaves. But I was expecting that when a view change occurs, nodes no longer in the view would be marked for removal (line 2193 of TP.java) and then after the logical_addr_cache_expiration has been reached and the reaper kicks in, once a new node joins, the expired cache entries would be purged from the file.
> I dug in to the code a bit, and what seems to be happening is that the MERGE3 protocol periodically generates a FIND_MBRS event. S3_PING retrieves the membership from the .list file, which includes expired nodes. And then all of these members are re-added to the logical address cache (line 157 of S3_PING.java, line 533 of Discovery.java, line 2263 of TP.java).
> So expired nodes are continually re-added to the logical address cache, preventing them from ever being reaped.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months