November 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9583) Drop org.jboss.as.test.clustering.single.jdbcstore.TransactionalJdbcStoreTestCase

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9583?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-9583: --------------------------------- Description: While the behaviour verification belongs to Infinspan rather than the AS, the dependent Jira is rejected https://issues.jboss.org/browse/ISPN-604. (was: The dependent Jira is rejected https://issues.jboss.org/browse/ISPN-604) > Drop org.jboss.as.test.clustering.single.jdbcstore.TransactionalJdbcStoreTestCase > --------------------------------------------------------------------------------- > > Key: WFLY-9583 > URL: https://issues.jboss.org/browse/WFLY-9583 > Project: WildFly > Issue Type: Task > Components: Clustering, Test Suite > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 12.0.0.Alpha1 > > > While the behaviour verification belongs to Infinspan rather than the AS, the dependent Jira is rejected https://issues.jboss.org/browse/ISPN-604. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9583) Drop org.jboss.as.test.clustering.single.jdbcstore.TransactionalJdbcStoreTestCase

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9583?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-9583: --------------------------------- Fix Version/s: 12.0.0.Alpha1 > Drop org.jboss.as.test.clustering.single.jdbcstore.TransactionalJdbcStoreTestCase > --------------------------------------------------------------------------------- > > Key: WFLY-9583 > URL: https://issues.jboss.org/browse/WFLY-9583 > Project: WildFly > Issue Type: Task > Components: Clustering, Test Suite > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 12.0.0.Alpha1 > > > While the behaviour verification belongs to Infinspan rather than the AS, the dependent Jira is rejected https://issues.jboss.org/browse/ISPN-604. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9583) Drop org.jboss.as.test.clustering.single.jdbcstore.TransactionalJdbcStoreTestCase

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-9583: ------------------------------------ Summary: Drop org.jboss.as.test.clustering.single.jdbcstore.TransactionalJdbcStoreTestCase Key: WFLY-9583 URL: https://issues.jboss.org/browse/WFLY-9583 Project: WildFly Issue Type: Task Components: Clustering, Test Suite Reporter: Radoslav Husar Assignee: Radoslav Husar The dependent Jira is rejected https://issues.jboss.org/browse/ISPN-604 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2146) kie-maven-plugin does not include package in error messages

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2146?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-2146: -------------------------------- Sprint: 2017 Week 47-48 > kie-maven-plugin does not include package in error messages > ----------------------------------------------------------- > > Key: DROOLS-2146 > URL: https://issues.jboss.org/browse/DROOLS-2146 > Project: Drools > Issue Type: Bug > Reporter: Alexandre Porcelli > Assignee: Mario Fusco > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2237) The single node in the cluster not become a coordinator after coordinator leave.

by kfir avraham (JIRA)

[ https://issues.jboss.org/browse/JGRP-2237?page=com.atlassian.jira.plugin.... ] kfir avraham commented on JGRP-2237: ------------------------------------ i attached another logs in trace mode, you can see from 'Nov-29-2017 *+00:24:08+* GMT-12:00 [org.jgroups.protocols.TCP] [TcpServer.Acceptor[8102]-5,clm-tlv-spih62-62502] [TRACE] - 10.63.16.13:8102: rejected connection from 10.63.16.3:8102 (connection existed and my address won as it's higher)' > The single node in the cluster not become a coordinator after coordinator leave. > -------------------------------------------------------------------------------- > > Key: JGRP-2237 > URL: https://issues.jboss.org/browse/JGRP-2237 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.2, 4.0.8 > Reporter: kfir avraham > Assignee: Bela Ban > Priority: Minor > Attachments: Server_A.txt, Server_A_Trace_mode.rtf, Server_B.txt, Server_B_Trace_mode.rtf, conf.txt, test.xml > > > I got cluster with 2 members, sometimes when the first node (coordinator) leave the cluster the second one is not become a coordinator. > When the first one is rejoin, he could not determine coordinator and select new one from the nodes list. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2237) The single node in the cluster not become a coordinator after coordinator leave.

by kfir avraham (JIRA)

[ https://issues.jboss.org/browse/JGRP-2237?page=com.atlassian.jira.plugin.... ] kfir avraham updated JGRP-2237: ------------------------------- Attachment: Server_A_Trace_mode.rtf Server_B_Trace_mode.rtf > The single node in the cluster not become a coordinator after coordinator leave. > -------------------------------------------------------------------------------- > > Key: JGRP-2237 > URL: https://issues.jboss.org/browse/JGRP-2237 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.2, 4.0.8 > Reporter: kfir avraham > Assignee: Bela Ban > Priority: Minor > Attachments: Server_A.txt, Server_A_Trace_mode.rtf, Server_B.txt, Server_B_Trace_mode.rtf, conf.txt, test.xml > > > I got cluster with 2 members, sometimes when the first node (coordinator) leave the cluster the second one is not become a coordinator. > When the first one is rejoin, he could not determine coordinator and select new one from the nodes list. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9582) server not starting from windows service

by Cheng Fang (JIRA)

[ https://issues.jboss.org/browse/WFLY-9582?page=com.atlassian.jira.plugin.... ] Cheng Fang updated WFLY-9582: ----------------------------- Component/s: (was: Batch) > server not starting from windows service > ---------------------------------------- > > Key: WFLY-9582 > URL: https://issues.jboss.org/browse/WFLY-9582 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 9.0.2.Final > Environment: Window 7 64-bit system > Reporter: Roshan Royal > Assignee: Cheng Fang > Priority: Blocker > > Getting below error while trying to start server through windows service. > [2017-11-29 14:24:47] [info] [14908] Commons Daemon procrun (1.0.15.0 64-bit) started > [2017-11-29 14:24:47] [info] [14908] Starting service 'Wildfly' ... > [2017-11-29 14:24:47] [info] [ 3760] Commons Daemon procrun (1.0.15.0 64-bit) started > [2017-11-29 14:24:47] [info] [ 3760] Running 'Wildfly' Service... > [2017-11-29 14:24:47] [info] [15500] Starting service... > [2017-11-29 14:24:47] [info] [15500] Service started in 3 ms. > [2017-11-29 14:24:47] [info] [ 3760] Run service finished. > [2017-11-29 14:24:47] [info] [ 3760] Commons Daemon procrun finished > [2017-11-29 14:24:48] [error] [14908] Failed to start 'Wildfly' service > [2017-11-29 14:24:48] [error] [14908] The data area passed to a system call is too small. > [2017-11-29 14:24:48] [info] [14908] Start service finished. > [2017-11-29 14:24:48] [error] [14908] Commons Daemon procrun failed with exit value: 5 (Failed to start service) > [2017-11-29 14:24:48] [error] [14908] The data area passed to a system call is too small. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9582) server not starting from windows service

by Cheng Fang (JIRA)

[ https://issues.jboss.org/browse/WFLY-9582?page=com.atlassian.jira.plugin.... ] Cheng Fang reassigned WFLY-9582: -------------------------------- Assignee: Tomaz Cerar (was: Cheng Fang) > server not starting from windows service > ---------------------------------------- > > Key: WFLY-9582 > URL: https://issues.jboss.org/browse/WFLY-9582 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 9.0.2.Final > Environment: Window 7 64-bit system > Reporter: Roshan Royal > Assignee: Tomaz Cerar > Priority: Blocker > > Getting below error while trying to start server through windows service. > [2017-11-29 14:24:47] [info] [14908] Commons Daemon procrun (1.0.15.0 64-bit) started > [2017-11-29 14:24:47] [info] [14908] Starting service 'Wildfly' ... > [2017-11-29 14:24:47] [info] [ 3760] Commons Daemon procrun (1.0.15.0 64-bit) started > [2017-11-29 14:24:47] [info] [ 3760] Running 'Wildfly' Service... > [2017-11-29 14:24:47] [info] [15500] Starting service... > [2017-11-29 14:24:47] [info] [15500] Service started in 3 ms. > [2017-11-29 14:24:47] [info] [ 3760] Run service finished. > [2017-11-29 14:24:47] [info] [ 3760] Commons Daemon procrun finished > [2017-11-29 14:24:48] [error] [14908] Failed to start 'Wildfly' service > [2017-11-29 14:24:48] [error] [14908] The data area passed to a system call is too small. > [2017-11-29 14:24:48] [info] [14908] Start service finished. > [2017-11-29 14:24:48] [error] [14908] Commons Daemon procrun failed with exit value: 5 (Failed to start service) > [2017-11-29 14:24:48] [error] [14908] The data area passed to a system call is too small. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2237) The single node in the cluster not become a coordinator after coordinator leave.

by kfir avraham (JIRA)

[ https://issues.jboss.org/browse/JGRP-2237?page=com.atlassian.jira.plugin.... ] kfir avraham edited comment on JGRP-2237 at 11/29/17 7:01 AM: -------------------------------------------------------------- i attached logs from server_A, server_B, and conf file. in this case (after upgrade to version 4.0.8) it is look better but from some reason after a few restarts, server_A doesn't sent a join message to the other machine, and create new view with 'is_coord-true'. any idea what could be the reason for that? BTW, we must to use in ' port_range="0" ', because we want to use only in this port, and it worked perfect in 3.6.11 version (we upgraded the version because security issue). when i set ' port_range="5" ', they not discovered each other from the beginning. *+Log in trace mode:+* Nov-28-2017 23:31:36 GMT-12:00 [org.jgroups.protocols.TCP] [main] [DEBUG] - thread pool min/max/keep-alive: 2/30/60000 use_fork_join=false, internal pool: 0/4/30000 (2 cores available) Nov-28-2017 23:31:36 GMT-12:00 [org.jgroups.protocols.pbcast.NAKACK2] [main] [TRACE] - null: set max_xmit_req_size from 0 to 247600 Nov-28-2017 23:31:36 GMT-12:00 [org.jgroups.protocols.UNICAST3] [main] [TRACE] - null: set max_xmit_req_size from 0 to 247600 Nov-28-2017 23:31:36 GMT-12:00 [org.jgroups.protocols.pbcast.STABLE] [main] [TRACE] - clm-tlv-spih31-6939: stable task started Nov-28-2017 23:31:36 GMT-12:00 [org.jgroups.protocols.TCPPING] [main] [TRACE] - clm-tlv-spih31-6939: sending discovery request to 10.63.16.13:8102 Nov-28-2017 23:31:36 GMT-12:00 [org.jgroups.protocols.TCP] [main] [TRACE] - clm-tlv-spih31-6939: sending msg to 10.63.16.13:8102, src=clm-tlv-spih31-6939, headers are TCPPING: [GET_MBRS_REQ cluster=HACluster initial_discovery=true], TP: [cluster_name=HACluster] Nov-28-2017 23:31:36 GMT-12:00 [org.jgroups.protocols.TCP] [TQ-Bundler-7,clm-tlv-spih31-6939] [TRACE] - 10.63.16.3:8102: +*connecting to 10.63.16.13:8102*+ Nov-28-2017 23:31:36 GMT-12:00 [org.jgroups.protocols.TCP] [Connection.Receiver [10.63.16.3:50534 - 10.63.16.13:8102]-9,clm-tlv-spih31-6939] [TRACE] - 10.63.16.3:8102: +*removed connection to 10.63.16.13:8102*+ Nov-28-2017 23:31:36 GMT-12:00 [org.jgroups.protocols.TCP] [TcpServer.Acceptor[8102]-5,clm-tlv-spih31-6939] [TRACE] - 10.63.16.3:8102: +*accepted connection from 10.63.16.13:8102*+ Nov-28-2017 23:31:37 GMT-12:00 [org.jgroups.protocols.pbcast.GMS] [main] [TRACE] - clm-tlv-spih31-6939: *+no members discovered after 1029 ms:+* creating cluster as first member Nov-28-2017 23:31:37 GMT-12:00 [org.jgroups.protocols.pbcast.NAKACK2] [main] [DEBUG] - [clm-tlv-spih31-6939 setDigest()] existing digest: [] new digest: clm-tlv-spih31-6939: [0 (0)] resulting digest: clm-tlv-spih31-6939: [0 (0)] Nov-28-2017 23:31:37 GMT-12:00 [org.jgroups.protocols.pbcast.GMS] [main] [DEBUG] - clm-tlv-spih31-6939: installing view [clm-tlv-spih31-6939|0] (1) [clm-tlv-spih31-6939] was (Author: kavraham): i attached logs from server_A, server_B, and conf file. in this case (after upgrade to version 4.0.8) it is look better but from some reason after a few restarts, server_A doesn't sent a join message to the other machine, and create new view with 'is_coord-true'. any idea what could be the reason for that? BTW, we must to use in ' port_range="0" ', because we want to use only in this port, and it worked perfect in 3.6.11 version (we upgraded the version because security issue). when i set ' port_range="5" ', they not discovered each other from the beginning. *+Log in trace mode:+* Nov-28-2017 23:31:36 GMT-12:00 [org.jgroups.protocols.TCP] [main] [DEBUG] - thread pool min/max/keep-alive: 2/30/60000 use_fork_join=false, internal pool: 0/4/30000 (2 cores available) Nov-28-2017 23:31:36 GMT-12:00 [org.jgroups.protocols.pbcast.NAKACK2] [main] [TRACE] - null: set max_xmit_req_size from 0 to 247600 Nov-28-2017 23:31:36 GMT-12:00 [org.jgroups.protocols.UNICAST3] [main] [TRACE] - null: set max_xmit_req_size from 0 to 247600 Nov-28-2017 23:31:36 GMT-12:00 [org.jgroups.protocols.pbcast.STABLE] [main] [TRACE] - clm-tlv-spih31-6939: stable task started Nov-28-2017 23:31:36 GMT-12:00 [org.jgroups.protocols.TCPPING] [main] [TRACE] - clm-tlv-spih31-6939: sending discovery request to 10.63.16.13:8102 Nov-28-2017 23:31:36 GMT-12:00 [org.jgroups.protocols.TCP] [main] [TRACE] - clm-tlv-spih31-6939: sending msg to 10.63.16.13:8102, src=clm-tlv-spih31-6939, headers are TCPPING: [GET_MBRS_REQ cluster=HACluster initial_discovery=true], TP: [cluster_name=HACluster] Nov-28-2017 23:31:36 GMT-12:00 [org.jgroups.protocols.TCP] [TQ-Bundler-7,clm-tlv-spih31-6939] [TRACE] - 10.63.16.3:8102: connecting to 10.63.16.13:8102 Nov-28-2017 23:31:36 GMT-12:00 [org.jgroups.protocols.TCP] [Connection.Receiver [10.63.16.3:50534 - 10.63.16.13:8102]-9,clm-tlv-spih31-6939] [TRACE] - 10.63.16.3:8102: removed connection to 10.63.16.13:8102 Nov-28-2017 23:31:36 GMT-12:00 [org.jgroups.protocols.TCP] [TcpServer.Acceptor[8102]-5,clm-tlv-spih31-6939] [TRACE] - 10.63.16.3:8102: accepted connection from 10.63.16.13:8102 Nov-28-2017 23:31:37 GMT-12:00 [org.jgroups.protocols.pbcast.GMS] [main] [TRACE] - clm-tlv-spih31-6939: no members discovered after 1029 ms: creating cluster as first member Nov-28-2017 23:31:37 GMT-12:00 [org.jgroups.protocols.pbcast.NAKACK2] [main] [DEBUG] - [clm-tlv-spih31-6939 setDigest()] existing digest: [] new digest: clm-tlv-spih31-6939: [0 (0)] resulting digest: clm-tlv-spih31-6939: [0 (0)] Nov-28-2017 23:31:37 GMT-12:00 [org.jgroups.protocols.pbcast.GMS] [main] [DEBUG] - clm-tlv-spih31-6939: installing view [clm-tlv-spih31-6939|0] (1) [clm-tlv-spih31-6939] > The single node in the cluster not become a coordinator after coordinator leave. > -------------------------------------------------------------------------------- > > Key: JGRP-2237 > URL: https://issues.jboss.org/browse/JGRP-2237 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.2, 4.0.8 > Reporter: kfir avraham > Assignee: Bela Ban > Priority: Minor > Attachments: Server_A.txt, Server_B.txt, conf.txt, test.xml > > > I got cluster with 2 members, sometimes when the first node (coordinator) leave the cluster the second one is not become a coordinator. > When the first one is rejoin, he could not determine coordinator and select new one from the nodes list. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2155) table editor should use full canvas area available

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2155?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-2155: -------------------------------- Tester: Jozef Marko > table editor should use full canvas area available > -------------------------------------------------- > > Key: DROOLS-2155 > URL: https://issues.jboss.org/browse/DROOLS-2155 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Reporter: Liz Clayton > Assignee: Michael Anstis > Priority: Minor > Labels: UX > > DMN table editor should use the full canvas width that is available (minus panels, toolbars, etc.) It should not appear as a smaller fixed size area, with scrollbars, within the canvas. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

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 November 2017