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 updated WFCORE-4357: ----------------------------------- Fix Version/s: 9.0.0.Beta2 > 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)

7 years, 1 month

1
0
0 / 0

[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)

7 years, 1 month

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)

7 years, 1 month

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)

7 years, 1 month

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)

7 years, 1 month

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)

7 years, 1 month

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)

7 years, 1 month

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)

7 years, 1 month

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)

7 years, 1 month

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)

7 years, 1 month

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 March 2019