March 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-4357) Support new MSC Service API for deployment dependency

by Richard Opalka (Jira)

[ https://issues.jboss.org/browse/WFCORE-4357?page=com.atlassian.jira.plugi... ] Richard Opalka reassigned WFCORE-4357: -------------------------------------- Assignee: Richard Opalka (was: Jeff Mesnil) > Support new MSC Service API for deployment dependency > ----------------------------------------------------- > > Key: WFCORE-4357 > URL: https://issues.jboss.org/browse/WFCORE-4357 > Project: WildFly Core > Issue Type: Bug > Components: Management > Reporter: Jan Stourac > Assignee: Richard Opalka > Priority: Major > Fix For: 9.0.0.Beta2 > > > When org.jboss.as.server.deployment.DeploymentPhaseContextImpl#addDeploymentDependency is used, it is expecting the service to be old-API org.jboss.msc.service.Service and use its getValue() method. > This needs to be fixed so that using new MSC Service API works too. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2335) Code for determining the coordinator hangs in certain conditions

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2335?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2335: --------------------------- Fix Version/s: 4.1.1 > Code for determining the coordinator hangs in certain conditions > ---------------------------------------------------------------- > > Key: JGRP-2335 > URL: https://issues.jboss.org/browse/JGRP-2335 > Project: JGroups > Issue Type: Bug > Reporter: Aieksiei Illarionov > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.1 > > > Affected version: > {code:xml} > <dependency> > <groupId>org.jgroups</groupId> > <artifactId>jgroups</artifactId> > <version>4.0.0.Final</version> > </dependency> > {code} > ClientGmsImpl#joinInternal hangs because #firstOfAllClients always returns false when all of the following conditions are satisfied: > - using JDBC_PING for discovery protocol > - JGROUPSPING table contains data from previous sessions > - all of the previous sessions were killed (kill -9) > - AddressGenerator is not customized > The sorted set > {code:java} > SortedSet<Address> clients=new TreeSet<>(); > {code} > contains the dead servers discovered from JGROUPSPING. When the new server is added to the sorted set, it never becomes the first in the sorted set. > Suggestions: either > a) somehow involve MembershipChangePolicy in ordering strategy, or > b) make the new server (joiner) the first in the sorted set, or > c) make UUID addresses to sort depending on their time of creation. > I've used the following config: > {code:xml} >  > <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns="urn:org:jgroups" > xmlns:fork="fork" > xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd fork http://www.jgroups.org/schema/fork-stacks.xsd"> > <TCP bind_port="7800" > port_range="10" > bind_addr="<placeholder here>" > recv_buf_size="${tcp.recv_buf_size:130k}" > send_buf_size="${tcp.send_buf_size:130k}" > max_bundle_size="64K" > sock_conn_timeout="300" > thread_pool.min_threads="0" > thread_pool.max_threads="20" > thread_pool.keep_alive_time="30000"/> > <JDBC_PING > remove_all_data_on_view_change="true" > connection_driver="com.microsoft.sqlserver.jdbc.SQLServerDriver" > connection_url="jdbc:sqlserver://localhost:1433;databaseName=mydatabase" > connection_username="user" > connection_password="password" > /> > <MERGE3 min_interval="10000" > max_interval="30000"/> > <FD_SOCK/> > <FD timeout="3000" max_tries="3" /> > <VERIFY_SUSPECT timeout="1500" /> > <BARRIER /> > <pbcast.NAKACK2 use_mcast_xmit="false" > discard_delivered_msgs="true"/> > <UNICAST3 > conn_close_timeout="240000" > xmit_interval="5000"/> > <pbcast.STABLE desired_avg_gossip="50000" > max_bytes="4M"/> > <pbcast.GMS print_local_addr="true" join_timeout="2000" > view_bundling="true" > membership_change_policy="ru.illar.AppMembershipChangePolicy"/> > <MFC max_credits="2M" > min_threshold="0.4"/> > <FRAG2 frag_size="60K" /> >  > <pbcast.STATE_TRANSFER/> > </config> > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1777) Add version 1.4 of the Elytron client schema

by Farah Juma (Jira)

Farah Juma created ELY-1777: ------------------------------- Summary: Add version 1.4 of the Elytron client schema Key: ELY-1777 URL: https://issues.jboss.org/browse/ELY-1777 Project: WildFly Elytron Issue Type: Task Components: Authentication Client Reporter: Farah Juma Assignee: Farah Juma -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11912) Component upgrade of Narayana to 5.8.4.Final

by Ondrej Chaloupka (Jira)

Ondrej Chaloupka created WFLY-11912: --------------------------------------- Summary: Component upgrade of Narayana to 5.8.4.Final Key: WFLY-11912 URL: https://issues.jboss.org/browse/WFLY-11912 Project: WildFly Issue Type: Component Upgrade Components: Transactions Affects Versions: 16.0.0.Final Reporter: Ondrej Chaloupka Assignee: Ondrej Chaloupka -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1797) Incorrect V&V results when operator is filled in the row (as opposed to column definition)

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-1797?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-1797: -------------------------------- Attachment: (was: Screenshot from 2019-03-27 20-59-00.png) > Incorrect V&V results when operator is filled in the row (as opposed to column definition) > ------------------------------------------------------------------------------------------ > > Key: DROOLS-1797 > URL: https://issues.jboss.org/browse/DROOLS-1797 > Project: Drools > Issue Type: Bug > Components: Guided Decision Table Editor > Affects Versions: 6.4.0.Final > Reporter: Anton Giertli > Assignee: Toni Rikkola > Priority: Major > Labels: drools-tools, support, verifier > Attachments: 6iOx.png > > > Imagine data model Person with attribute age. > If you create decision table and add two columns: > - both are defined against "age" attribute > - none of them have operator defined > then you add one row, and you fill in the operator and the value directly inside the row. > For example: > >= 20 > <= 30 > The generated DRL looks like this: > {code:java} > package org; > //from row number: 1 > rule "Row 1 AnotherTest" > dialect "mvel" > when > p : Person( age >= 20 , age <= 30 ) > then > p.setAgeGroup( "whatever" ); > end > {code} > The V&V will report this as conflicting row: > !6iOx.png|thumbnail! -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1797) Incorrect V&V results when operator is filled in the row (as opposed to column definition)

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-1797?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-1797: -------------------------------- Attachment: (was: MySpace_a.zip) > Incorrect V&V results when operator is filled in the row (as opposed to column definition) > ------------------------------------------------------------------------------------------ > > Key: DROOLS-1797 > URL: https://issues.jboss.org/browse/DROOLS-1797 > Project: Drools > Issue Type: Bug > Components: Guided Decision Table Editor > Affects Versions: 6.4.0.Final > Reporter: Anton Giertli > Assignee: Toni Rikkola > Priority: Major > Labels: drools-tools, support, verifier > Attachments: 6iOx.png > > > Imagine data model Person with attribute age. > If you create decision table and add two columns: > - both are defined against "age" attribute > - none of them have operator defined > then you add one row, and you fill in the operator and the value directly inside the row. > For example: > >= 20 > <= 30 > The generated DRL looks like this: > {code:java} > package org; > //from row number: 1 > rule "Row 1 AnotherTest" > dialect "mvel" > when > p : Person( age >= 20 , age <= 30 ) > then > p.setAgeGroup( "whatever" ); > end > {code} > The V&V will report this as conflicting row: > !6iOx.png|thumbnail! -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1797) Incorrect V&V results when operator is filled in the row (as opposed to column definition)

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-1797?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-1797: -------------------------------- Attachment: Screenshot from 2019-03-27 20-59-00.png > Incorrect V&V results when operator is filled in the row (as opposed to column definition) > ------------------------------------------------------------------------------------------ > > Key: DROOLS-1797 > URL: https://issues.jboss.org/browse/DROOLS-1797 > Project: Drools > Issue Type: Bug > Components: Guided Decision Table Editor > Affects Versions: 6.4.0.Final > Reporter: Anton Giertli > Assignee: Toni Rikkola > Priority: Major > Labels: drools-tools, support, verifier > Attachments: 6iOx.png, MySpace_a.zip, Screenshot from 2019-03-27 20-59-00.png > > > Imagine data model Person with attribute age. > If you create decision table and add two columns: > - both are defined against "age" attribute > - none of them have operator defined > then you add one row, and you fill in the operator and the value directly inside the row. > For example: > >= 20 > <= 30 > The generated DRL looks like this: > {code:java} > package org; > //from row number: 1 > rule "Row 1 AnotherTest" > dialect "mvel" > when > p : Person( age >= 20 , age <= 30 ) > then > p.setAgeGroup( "whatever" ); > end > {code} > The V&V will report this as conflicting row: > !6iOx.png|thumbnail! -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1797) Incorrect V&V results when operator is filled in the row (as opposed to column definition)

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-1797?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-1797: -------------------------------- Attachment: MySpace_a.zip > Incorrect V&V results when operator is filled in the row (as opposed to column definition) > ------------------------------------------------------------------------------------------ > > Key: DROOLS-1797 > URL: https://issues.jboss.org/browse/DROOLS-1797 > Project: Drools > Issue Type: Bug > Components: Guided Decision Table Editor > Affects Versions: 6.4.0.Final > Reporter: Anton Giertli > Assignee: Toni Rikkola > Priority: Major > Labels: drools-tools, support, verifier > Attachments: 6iOx.png, MySpace_a.zip, Screenshot from 2019-03-27 20-59-00.png > > > Imagine data model Person with attribute age. > If you create decision table and add two columns: > - both are defined against "age" attribute > - none of them have operator defined > then you add one row, and you fill in the operator and the value directly inside the row. > For example: > >= 20 > <= 30 > The generated DRL looks like this: > {code:java} > package org; > //from row number: 1 > rule "Row 1 AnotherTest" > dialect "mvel" > when > p : Person( age >= 20 , age <= 30 ) > then > p.setAgeGroup( "whatever" ); > end > {code} > The V&V will report this as conflicting row: > !6iOx.png|thumbnail! -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11807) FD_SOCK socket-binding client mappings do not map to external_addr/port properly

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-11807?page=com.atlassian.jira.plugin... ] Paul Ferraro updated WFLY-11807: -------------------------------- Summary: FD_SOCK socket-binding client mappings do not map to external_addr/port properly (was: Better port configuration for JGroups FD_SOCK) > FD_SOCK socket-binding client mappings do not map to external_addr/port properly > -------------------------------------------------------------------------------- > > Key: WFLY-11807 > URL: https://issues.jboss.org/browse/WFLY-11807 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 14.0.0.Final > Reporter: Rich DiCroce > Assignee: Paul Ferraro > Priority: Major > > The JGroups FD_SOCK protocol requires 2 TCP sockets. Older versions of WildFly accepted a socket-binding for this protocol, but that was removed around version 11, apparently because the binding's port number [wasn't actually used|https://access.redhat.com/solutions/3485801]. > Now the port selection is random by default, which is a problem if you've got firewalls to deal with, as noted in the linked document. The suggested workaround is to set the client_bind_port and start_port properties of the protocol, but that has the drawback of not being affected by a socket-binding-group's port-offset. This means that if you want to run 2 WildFly instances on the same box with the same config (which I do, as a developer, to test application code related to clustering), simply changing the port offset is insufficient to get the second instance to start. > So I'd like to suggest that socket-binding for FD_SOCK be resurrected, given that it can be implemented correctly now. FD_SOCK calls the configured SocketFactory for both the server socket (with name jgroups.fd_sock.srv_sock) and the client socket (with name jgroups.fd.ping_sock), so it should be possible for WildFly to fully manage the socket bindings. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2335) Code for determining the coordinator hangs in certain conditions

by Aieksiei Illarionov (Jira)

Aieksiei Illarionov created JGRP-2335: ----------------------------------------- Summary: Code for determining the coordinator hangs in certain conditions Key: JGRP-2335 URL: https://issues.jboss.org/browse/JGRP-2335 Project: JGroups Issue Type: Bug Reporter: Aieksiei Illarionov Assignee: Bela Ban Affected version: {code:xml} <dependency> <groupId>org.jgroups</groupId> <artifactId>jgroups</artifactId> <version>4.0.0.Final</version> </dependency> {code} ClientGmsImpl#joinInternal hangs because #firstOfAllClients always returns false when all of the following conditions are satisfied: - using JDBC_PING for discovery protocol - JGROUPSPING table contains data from previous sessions - all of the previous sessions were killed (kill -9) - AddressGenerator is not customized The sorted set {code:java} SortedSet<Address> clients=new TreeSet<>(); {code} contains the dead servers discovered from JGROUPSPING. When the new server is added to the sorted set, it never becomes the first in the sorted set. Suggestions: either a) somehow involve MembershipChangePolicy in ordering strategy, or b) make the new server (joiner) the first in the sorted set, or c) make UUID addresses to sort depending on their time of creation. I've used the following config: {code:xml}  <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:org:jgroups" xmlns:fork="fork" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd fork http://www.jgroups.org/schema/fork-stacks.xsd"> <TCP bind_port="7800" port_range="10" bind_addr="<placeholder here>" recv_buf_size="${tcp.recv_buf_size:130k}" send_buf_size="${tcp.send_buf_size:130k}" max_bundle_size="64K" sock_conn_timeout="300" thread_pool.min_threads="0" thread_pool.max_threads="20" thread_pool.keep_alive_time="30000"/> <JDBC_PING remove_all_data_on_view_change="true" connection_driver="com.microsoft.sqlserver.jdbc.SQLServerDriver" connection_url="jdbc:sqlserver://localhost:1433;databaseName=mydatabase" connection_username="user" connection_password="password" /> <MERGE3 min_interval="10000" max_interval="30000"/> <FD_SOCK/> <FD timeout="3000" max_tries="3" /> <VERIFY_SUSPECT timeout="1500" /> <BARRIER /> <pbcast.NAKACK2 use_mcast_xmit="false" discard_delivered_msgs="true"/> <UNICAST3 conn_close_timeout="240000" xmit_interval="5000"/> <pbcast.STABLE desired_avg_gossip="50000" max_bytes="4M"/> <pbcast.GMS print_local_addr="true" join_timeout="2000" view_bundling="true" membership_change_policy="ru.illar.AppMembershipChangePolicy"/> <MFC max_credits="2M" min_threshold="0.4"/> <FRAG2 frag_size="60K" />  <pbcast.STATE_TRANSFER/> </config> {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2019