June 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8935) Upgrade JSF based on Mojarra 2.2.13.SP4

by Bartosz Spyrko-Śmietanko (JIRA)

[ https://issues.jboss.org/browse/WFLY-8935?page=com.atlassian.jira.plugin.... ] Bartosz Spyrko-Śmietanko reassigned WFLY-8935: ---------------------------------------------- Assignee: Bartosz Spyrko-Śmietanko (was: Farah Juma) > Upgrade JSF based on Mojarra 2.2.13.SP4 > --------------------------------------- > > Key: WFLY-8935 > URL: https://issues.jboss.org/browse/WFLY-8935 > Project: WildFly > Issue Type: Component Upgrade > Components: JSF > Affects Versions: 11.0.0.Alpha1 > Reporter: Bartosz Spyrko-Śmietanko > Assignee: Bartosz Spyrko-Śmietanko > Fix For: 11.0.0.Alpha1 > > > Upgrade JSF based on Mojarra 2.2.13.SP4. This incorporates the patch for JBEAP-10758/[JAVASERVERFACES-4240 | https://java.net/jira/browse/JAVASERVERFACES-4240] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8935) Upgrade JSF based on Mojarra 2.2.13.SP4

by Bartosz Spyrko-Śmietanko (JIRA)

[ https://issues.jboss.org/browse/WFLY-8935?page=com.atlassian.jira.plugin.... ] Bartosz Spyrko-Śmietanko updated WFLY-8935: ------------------------------------------- Description: Upgrade JSF based on Mojarra 2.2.13.SP4. This incorporates the patch for JBEAP-10758/[JAVASERVERFACES-4240 | https://java.net/jira/browse/JAVASERVERFACES-4240] (was: Upgrade JSF based on Mojarra 2.2.13.SP3. This incorporates the patch for WFLY-6889/[JAVASERVERFACES-4077 | https://java.net/jira/browse/JAVASERVERFACES-4077] for WildFly 11.0.0.Alpha1.) > Upgrade JSF based on Mojarra 2.2.13.SP4 > --------------------------------------- > > Key: WFLY-8935 > URL: https://issues.jboss.org/browse/WFLY-8935 > Project: WildFly > Issue Type: Component Upgrade > Components: JSF > Affects Versions: 11.0.0.Alpha1 > Reporter: Bartosz Spyrko-Śmietanko > Assignee: Farah Juma > Fix For: 11.0.0.Alpha1 > > > Upgrade JSF based on Mojarra 2.2.13.SP4. This incorporates the patch for JBEAP-10758/[JAVASERVERFACES-4240 | https://java.net/jira/browse/JAVASERVERFACES-4240] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2195) [JGRP00012] discarded message from different cluster with JGroups Upgrade

by Swathi Kumar (JIRA)

[ https://issues.jboss.org/browse/JGRP-2195?page=com.atlassian.jira.plugin.... ] Swathi Kumar updated JGRP-2195: ------------------------------- Description: Greetings Team. We recently upgraded the jgroups jars from version 2_5_2/jgroups-all.jar to 3_4_0/jgroups-3.4.0.Alpha2.jar. With the upgrade we are seeing *[JGRP00012] discarded message from different cluster* messages every alternate seconds on all the nodes in the cluster. Also it is to be noted that this issue started to recur only when we switched the protocol from UDP to TCP. If we start using UDP again, we no longer see these *WARN* messages. We no longer support UDP in our application and we can't be using UDP anymore. We have several 100's of customers in the field who are using our product with this upgraded jgroups jar and have started to raise tickets against our product. We are clueless as to why the upgrade is producing enormous WARN messages - is there an issue with this version of the jgroups jar? The sample WARN message is shown below :- [2017-06-13 11:56:38.117] ALL 000000000000 GLOBAL_SCOPE 141694 [OOB-1,Sterling_NodeInfo_group,dublr005vm-24633] WARN org.jgroups.protocols.TCP - [JGRP00012] discarded message from different cluster Sterling_NodeInfo_group_WFC (our cluster is Sterling_NodeInfo_group). Sender was dublr005vm-2060 [2017-06-13 11:56:41.72] ALL 000000000000 GLOBAL_SCOPE 145297 [OOB-1,Sterling_NodeInfo_group_WFC,dublr005vm-2060] WARN org.jgroups.protocols.TCP - [JGRP00012] discarded message from different cluster Sterling_NodeInfo_group (our cluster is Sterling_NodeInfo_group_WFC). Sender was dublr005vm-24633 We have the below jgroups config properties in our application to create 3 channels (for security reasons have used a dummy host name here) :- jgroups_cluster.property_string=TCP(bind_addr=host_name_A;bind_port=34061):TCPPING(initial_hosts=host_name_A[34061],host_name_A[44061],host_name_A[54061];port_range=1;timeout=5000;num_initial_members=2):MERGE2(min_interval=3000;max_interval=5000):FD_ALL(interval=5000;timeout=20000):FD(timeout=5000;max_tries=48):VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(retransmit_timeout=100,200,300,600,1200,2400,4800;discard_delivered_msgs=true):pbcast.STABLE(stability_delay=1000;desired_avg_gossip=20000;max_bytes=0):pbcast.GMS(print_local_addr=true;join_timeout=5000) jgroups_cluster.distribution_property_string=TCP(bind_port= 34060;thread_pool_rejection_policy=run):TCPPING(initial_hosts=host_name_A[34060],host_name_A[44060],host_name_A[54060];port_range=1;timeout=5000;num_initial_members=2):MERGE2(min_interval=3000;max_interval=5000):FD_SOCK:FD(timeout=5000;max_tries=48):VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(retransmit_timeout=3000;discard_delivered_msgs=true):pbcast.STABLE(stability_delay=1000;desired_avg_gossip=20000;max_bytes=0):pbcast.GMS(join_timeout=5000;print_local_addr=true) jgroups_cluster.lock.protocolStack=TCP(bind_addr=host_name_A;bind_port=34062;):TCPPING(initial_hosts=host_name_A[34062],host_name_A[44062],host_name_A[54062];port_range=1;timeout=5000;num_initial_members=2):MERGE2(min_interval=3000;max_interval=5000):FD_ALL(interval=5000;timeout=20000):FD(timeout=5000;max_tries=48):VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(retransmit_timeout=100,200,300,600,1200,2400,4800;discard_delivered_msgs=true):pbcast.STABLE(stability_delay=1000;desired_avg_gossip=20000;max_bytes=0):pbcast.GMS(print_local_addr=true;join_timeout=5000) Test considerations :- 1. For in-house testing, I have created a 3 node cluster. 2. All the 3 nodes reside on the same box. If you need any further information please let me know. Regards Swathi BN was: Greetings Team. We recently upgraded the jgroups jars from version 2_5_2/jgroups-all.jar to 3_4_0/jgroups-3.4.0.Alpha2.jar. With the upgrade we are seeing *[JGRP00012] discarded message from different cluster* messages every alternate seconds on all the nodes in the cluster. Also it is to be noted that this issue started to recur only when we switched the protocol from UDP to TCP. If we start using UDP again, we no longer see these *WARN* messages. We no longer support UDP in our application and we can't be using UDP anymore. We have several 100's of customers in the field who are using our product with this upgraded jgroups jar and have started to raise tickets against our product. We are clueless as to why the upgrade is producing enormous WARN messages - is there an issue with this version of the jgroups jar? The sample WARN message is shown below :- [2017-06-13 11:56:38.117] ALL 000000000000 GLOBAL_SCOPE 141694 [OOB-1,Sterling_NodeInfo_group,dublr005vm-24633] WARN org.jgroups.protocols.TCP - [JGRP00012] discarded message from different cluster Sterling_NodeInfo_group_WFC (our cluster is Sterling_NodeInfo_group). Sender was dublr005vm-2060 [2017-06-13 11:56:41.72] ALL 000000000000 GLOBAL_SCOPE 145297 [OOB-1,Sterling_NodeInfo_group_WFC,dublr005vm-2060] WARN org.jgroups.protocols.TCP - [JGRP00012] discarded message from different cluster Sterling_NodeInfo_group (our cluster is Sterling_NodeInfo_group_WFC). Sender was dublr005vm-24633 We have the below jgroups config properties in our application to create 3 channels (for security reasons have used a dummy host name here) :- jgroups_cluster.property_string=TCP(bind_addr=host_name_A;bind_port=34061):TCPPING(initial_hosts=host_name_A[34061],host_name_A[44061],host_name_A[54061];port_range=1;timeout=5000;num_initial_members=2):MERGE2(min_interval=3000;max_interval=5000):FD_ALL(interval=5000;timeout=20000):FD(timeout=5000;max_tries=48):VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(retransmit_timeout=100,200,300,600,1200,2400,4800;discard_delivered_msgs=true):pbcast.STABLE(stability_delay=1000;desired_avg_gossip=20000;max_bytes=0):pbcast.GMS(print_local_addr=true;join_timeout=5000) jgroups_cluster.distribution_property_string=TCP(bind_port= 34061;thread_pool_rejection_policy=run):TCPPING(initial_hosts=host_name_A[34061],host_name_A[44061],host_name_A[54061];port_range=1;timeout=5000;num_initial_members=2):MERGE2(min_interval=3000;max_interval=5000):FD_SOCK:FD(timeout=5000;max_tries=48):VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(retransmit_timeout=3000;discard_delivered_msgs=true):pbcast.STABLE(stability_delay=1000;desired_avg_gossip=20000;max_bytes=0):pbcast.GMS(join_timeout=5000;print_local_addr=true) jgroups_cluster.lock.protocolStack=TCP(bind_addr=host_name_A;bind_port=34062;):TCPPING(initial_hosts=host_name_A[34062],host_name_A[44062],host_name_A[54062];port_range=1;timeout=5000;num_initial_members=2):MERGE2(min_interval=3000;max_interval=5000):FD_ALL(interval=5000;timeout=20000):FD(timeout=5000;max_tries=48):VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(retransmit_timeout=100,200,300,600,1200,2400,4800;discard_delivered_msgs=true):pbcast.STABLE(stability_delay=1000;desired_avg_gossip=20000;max_bytes=0):pbcast.GMS(print_local_addr=true;join_timeout=5000) Test considerations :- 1. For in-house testing, I have created a 3 node cluster. 2. All the 3 nodes reside on the same box. If you need any further information please let me know. Regards Swathi BN > [JGRP00012] discarded message from different cluster with JGroups Upgrade > ------------------------------------------------------------------------- > > Key: JGRP-2195 > URL: https://issues.jboss.org/browse/JGRP-2195 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.4 > Environment: All OS(Linux, AIX, Windows, Solaris) > Reporter: Swathi Kumar > Assignee: Bela Ban > > Greetings Team. > We recently upgraded the jgroups jars from version 2_5_2/jgroups-all.jar to 3_4_0/jgroups-3.4.0.Alpha2.jar. > With the upgrade we are seeing *[JGRP00012] discarded message from different cluster* messages every alternate seconds on all the nodes in the cluster. > Also it is to be noted that this issue started to recur only when we switched the protocol from UDP to TCP. If we start using UDP again, we no longer see these *WARN* messages. > We no longer support UDP in our application and we can't be using UDP anymore. > We have several 100's of customers in the field who are using our product with this upgraded jgroups jar and have started to raise tickets against our product. > We are clueless as to why the upgrade is producing enormous WARN messages - is there an issue with this version of the jgroups jar? > The sample WARN message is shown below :- > [2017-06-13 11:56:38.117] ALL 000000000000 GLOBAL_SCOPE 141694 [OOB-1,Sterling_NodeInfo_group,dublr005vm-24633] WARN org.jgroups.protocols.TCP - [JGRP00012] discarded message from different cluster Sterling_NodeInfo_group_WFC (our cluster is Sterling_NodeInfo_group). Sender was dublr005vm-2060 > [2017-06-13 11:56:41.72] ALL 000000000000 GLOBAL_SCOPE 145297 [OOB-1,Sterling_NodeInfo_group_WFC,dublr005vm-2060] WARN org.jgroups.protocols.TCP - [JGRP00012] discarded message from different cluster Sterling_NodeInfo_group (our cluster is Sterling_NodeInfo_group_WFC). Sender was dublr005vm-24633 > We have the below jgroups config properties in our application to create 3 channels (for security reasons have used a dummy host name here) :- > jgroups_cluster.property_string=TCP(bind_addr=host_name_A;bind_port=34061):TCPPING(initial_hosts=host_name_A[34061],host_name_A[44061],host_name_A[54061];port_range=1;timeout=5000;num_initial_members=2):MERGE2(min_interval=3000;max_interval=5000):FD_ALL(interval=5000;timeout=20000):FD(timeout=5000;max_tries=48):VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(retransmit_timeout=100,200,300,600,1200,2400,4800;discard_delivered_msgs=true):pbcast.STABLE(stability_delay=1000;desired_avg_gossip=20000;max_bytes=0):pbcast.GMS(print_local_addr=true;join_timeout=5000) > jgroups_cluster.distribution_property_string=TCP(bind_port= 34060;thread_pool_rejection_policy=run):TCPPING(initial_hosts=host_name_A[34060],host_name_A[44060],host_name_A[54060];port_range=1;timeout=5000;num_initial_members=2):MERGE2(min_interval=3000;max_interval=5000):FD_SOCK:FD(timeout=5000;max_tries=48):VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(retransmit_timeout=3000;discard_delivered_msgs=true):pbcast.STABLE(stability_delay=1000;desired_avg_gossip=20000;max_bytes=0):pbcast.GMS(join_timeout=5000;print_local_addr=true) > jgroups_cluster.lock.protocolStack=TCP(bind_addr=host_name_A;bind_port=34062;):TCPPING(initial_hosts=host_name_A[34062],host_name_A[44062],host_name_A[54062];port_range=1;timeout=5000;num_initial_members=2):MERGE2(min_interval=3000;max_interval=5000):FD_ALL(interval=5000;timeout=20000):FD(timeout=5000;max_tries=48):VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(retransmit_timeout=100,200,300,600,1200,2400,4800;discard_delivered_msgs=true):pbcast.STABLE(stability_delay=1000;desired_avg_gossip=20000;max_bytes=0):pbcast.GMS(print_local_addr=true;join_timeout=5000) > Test considerations :- > 1. For in-house testing, I have created a 3 node cluster. > 2. All the 3 nodes reside on the same box. > If you need any further information please let me know. > Regards > Swathi BN -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8935) Upgrade JSF based on Mojarra 2.2.13.SP4

by Bartosz Spyrko-Śmietanko (JIRA)

Bartosz Spyrko-Śmietanko created WFLY-8935: ---------------------------------------------- Summary: Upgrade JSF based on Mojarra 2.2.13.SP4 Key: WFLY-8935 URL: https://issues.jboss.org/browse/WFLY-8935 Project: WildFly Issue Type: Component Upgrade Components: JSF Affects Versions: 11.0.0.Alpha1 Reporter: Bartosz Spyrko-Śmietanko Assignee: Farah Juma Fix For: 11.0.0.Alpha1 Upgrade JSF based on Mojarra 2.2.13.SP3. This incorporates the patch for WFLY-6889/[JAVASERVERFACES-4077 | https://java.net/jira/browse/JAVASERVERFACES-4077] for WildFly 11.0.0.Alpha1. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1205) Wildfly Elytron Tool, Wildfly Elytron Tool error output would contain error message rather than stacktrace.

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/ELY-1205?page=com.atlassian.jira.plugin.s... ] Ilia Vassilev updated ELY-1205: ------------------------------- Git Pull Request: https://github.com/wildfly-security/wildfly-elytron-tool/pull/72, https://github.com/wildfly-security/wildfly-elytron-tool/pull/82 (was: https://github.com/wildfly-security/wildfly-elytron-tool/pull/72) > Wildfly Elytron Tool, Wildfly Elytron Tool error output would contain error message rather than stacktrace. > ----------------------------------------------------------------------------------------------------------- > > Key: ELY-1205 > URL: https://issues.jboss.org/browse/ELY-1205 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Hynek Švábek > Assignee: Ilia Vassilev > Priority: Blocker > > Wildfly Elytron Tool error output would contain error message rather than stacktrace. > I understand that it is very useful but the behaviour must be consistent with other apps, e.g.: jboss-cli. > Now we have inconsistency even in this tool - half exceptions, half error messages. > Here is example > {code} > java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret secretpassword --location="test.store1" --password secret_password --summary --salt 12345678 --iteration 230 --create -type=KeyStoreCredentialStore123 > Exception encountered executing the command: > java.security.NoSuchAlgorithmException > at org.wildfly.security.credential.store.CredentialStore.getInstance(CredentialStore.java:65) > at org.wildfly.security.tool.CredentialStoreCommand.execute(CredentialStoreCommand.java:157) > at org.wildfly.security.tool.ElytronTool.main(ElytronTool.java:75) > {code} > I suggest add application parameter \-\-verbose (\-\-debug, ...) which enables print stack trace when error occurs. > By default there is expected only error message and with this parameter there will be printed stack trace. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8934) JGroups backward compatibility - adding AUTH with deprecated operations fails

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-8934?page=com.atlassian.jira.plugin.... ] Paul Ferraro moved JBEAP-11550 to WFLY-8934: -------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8934 (was: JBEAP-11550) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Clustering (was: Clustering) Affects Version/s: 11.0.0.Alpha1 (was: 7.1.0.ER1) > JGroups backward compatibility - adding AUTH with deprecated operations fails > ----------------------------------------------------------------------------- > > Key: WFLY-8934 > URL: https://issues.jboss.org/browse/WFLY-8934 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 11.0.0.Alpha1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > See https://issues.jboss.org/browse/JBEAP-11190?focusedCommentId=13419465&pag..., point #3. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2874) It should not be possible to set negative values to IO worker attributes

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2874?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2874: ------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2537 (was: https://issues.jboss.org/browse/WFCORE-2874) > It should not be possible to set negative values to IO worker attributes > ------------------------------------------------------------------------ > > Key: WFCORE-2874 > URL: https://issues.jboss.org/browse/WFCORE-2874 > Project: WildFly Core > Issue Type: Bug > Components: IO > Reporter: Dmitrii Tikhomirov > Assignee: Dmitrii Tikhomirov > Fix For: 3.0.0.Beta27 > > > Following IO worker attributes can be set to negative values which in this context doesn't make sense: > * {{io-threads}} > * {{stack-size}} > * {{task-keepalive}} > * {{task-max-threads}} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8523) Create CommandDispatcher Quickstart

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-8523?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-8523: --------------------------------- Summary: Create CommandDispatcher Quickstart (was: Create Command Dispatcher Quickstart) > Create CommandDispatcher Quickstart > ----------------------------------- > > Key: WFLY-8523 > URL: https://issues.jboss.org/browse/WFLY-8523 > Project: WildFly > Issue Type: Task > Components: Clustering, Quickstarts > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > Demonstrate public clustering API which facilitates remote command execution on the cluster in package {{org.wildfly.clustering.dispatcher}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8523) Create CommandDispatcher Quickstart

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-8523?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-8523: --------------------------------- Fix Version/s: (was: Awaiting Volunteers) > Create CommandDispatcher Quickstart > ----------------------------------- > > Key: WFLY-8523 > URL: https://issues.jboss.org/browse/WFLY-8523 > Project: WildFly > Issue Type: Task > Components: Clustering, Quickstarts > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > Demonstrate public clustering API which facilitates remote command execution on the cluster in package {{org.wildfly.clustering.dispatcher}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8541) Create SingletonService quickstart

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-8541?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-8541: --------------------------------- Fix Version/s: 11.0.0.Beta1 > Create SingletonService quickstart > ---------------------------------- > > Key: WFLY-8541 > URL: https://issues.jboss.org/browse/WFLY-8541 > Project: WildFly > Issue Type: Task > Components: Clustering, Quickstarts > Affects Versions: 11.0.0.Alpha1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 11.0.0.Beta1 > > > Create a useful quickstart that does something other than using EE lookup from MSC to demonstrate org.wildfly.clustering.singleton.SingletonService. See [1] for more info. > [1] https://issues.jboss.org/browse/JBEAP-4004?focusedCommentId=13184169&page... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 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 June 2017