[JBoss JIRA] (JGRP-2172) Non-blocking flow control
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/JGRP-2172?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on JGRP-2172:
-----------------------------------
I would prefer fair ordering to preferring threads vs messages.
The queue could accept two things: either messages or thread tokens. When the {{NB_FC}} is not set and there's not enough credits, the thread adds a token to the queue, waiting for it to be released from the queue. When the credits arrive, messages and tokens would be served FIFO because of the queue.
> Non-blocking flow control
> -------------------------
>
> Key: JGRP-2172
> URL: https://issues.jboss.org/browse/JGRP-2172
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.4
>
>
> Sending a message through FlowControl (UFC, MFC) should not block if {{Message.Flag.NB_FC}} (non-blocking flow control) is set.
> Instead, the message should be added to a queue (bounded if {{max_size}} > 0, else unbounded). The max queue size is given in bytes, so we can estimate what the memory penalty for reaching that size would be (if bounded).
> The queued messages are sent when credits arrive. TBD: when credits arrive, should blocked threads or queued messages be released first?
> Non-blocking flow control can be used by both external and internal threads.
> If the queue is unbounded, then it is the responsibility of the application (e.g. Infinispan) to make sure the queue doesn't grow to an untenable size.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8937) Management/security-realm/authentication/users integration with credential reference is not correct.
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/WFLY-8937?page=com.atlassian.jira.plugin.... ]
Hynek Švábek updated WFLY-8937:
-------------------------------
Steps to Reproduce:
* Copy cs001.jceks keystore from attachment to JBOSS_HOME/standalone/data location or update path on attached standalone.xml
* Run EAP server with standalone.xml configuration file which is attached.
* There are defined three users one uses password and others use credential store (clear-text password and store + alias)
** go to http://localhost:9990/console/App.html and use pepa/pepa123 credentials - it works (uses password attribute)
** go to http://localhost:9990/console/App.html and use hynek/hynek123 credentials - it doesn't work (uses credential-reference and store + alias)
** go to http://localhost:9990/console/App.html and use ondra/ondra123 credentials - it doesn't work (uses credential-reference and clear-text password)
* You can create your own credential store like that
{code}
/subsystem=elytron/credential-store=cs002:add(create=true, location=cs002.jceks, relative-to="jboss.server.data.dir", credential-reference={clear-text=pass123})
{code}
* You can add there new alias to credential store like that
{code}
/subsystem=elytron/credential-store=cs002:add-alias(alias=newuseralias, secret-value=newuser123)
{code}
* and then add there new authentication user for management like that
{code}
/core-service=management/security-realm=ManagementRealm/authentication=users/user=newuser:add(credential-reference={store=cs002, alias=newuseralias})
{code}
Then you can try log in to management console http://localhost:9990/console/App.html
newuser/newuser123
was:
* Copy cs001.jceks keystore from attachment to JBOSS_HOME/standalone/data location or update path on attached standalone.xml
* Run EAP server with standalone.xml configuration file which is attached.
* There are defined three users one uses password and others use credential store (clear-text password and store + alias)
** go to http://localhost:9990/console/App.html and use pepa/pepa123 credentials - it works (uses password attribute)
** go to http://localhost:9990/console/App.html and use hynek/hynek123 credentials - it doesn't work (uses credential-reference and store + alias)
** go to http://localhost:9990/console/App.html and use ondra/ondra123 credentials - it doesn't work (uses credential-reference and clear-text password)
* You can add there new alias to credential store like that
{code}
/subsystem=elytron/credential-store=cs001:add-alias(alias=newuseralias, secret-value=newuser123)
{code}
* and then add there new authentication user for management like that
{code}
/core-service=management/security-realm=ManagementRealm/authentication=users/user=newuser:add(credential-reference={store=cs001, alias=newuseralias})
{code}
Then you can try log in to management console http://localhost:9990/console/App.html
newuser/newuser123
> Management/security-realm/authentication/users integration with credential reference is not correct.
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-8937
> URL: https://issues.jboss.org/browse/WFLY-8937
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> Management/security-realm/authentication/users integration with credential reference is not correct.
> When user set authentication/users instead of authentication/properties and add there user who has defined credential-reference then he is not able to log in to management console.
> It must work, please check *Steps to Reproduce* section.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-4790) Getting DirectBuffer OOM when sending fragmented binary message to websocket endpoint
by cosmin cosmin (JIRA)
[ https://issues.jboss.org/browse/WFLY-4790?page=com.atlassian.jira.plugin.... ]
cosmin cosmin commented on WFLY-4790:
-------------------------------------
It works and starts without my application but if I try to deploy my .ear the exceptions appear:
10:40:53,720 ERROR [ServiceControllerImpl$StartTask] (MSC service thread 1-4) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./my-commons-ejb.UndertowDeploymentInfoService: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./my-commons-ejb.UndertowDeploymentInfoService: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_92]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_92]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_92]
Caused by: java.lang.NoSuchMethodError: io.undertow.servlet.api.DeploymentInfo.setDisableCachingForSecuredPages(Z)V
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:592)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:265)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
... 3 more
10:40:53,723 ERROR [ServiceControllerImpl$StartTask] (MSC service thread 1-6) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./my-server.UndertowDeploymentInfoService: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./my-server.UndertowDeploymentInfoService: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_92]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_92]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_92]
Caused by: java.lang.NoSuchMethodError: io.undertow.servlet.api.DeploymentInfo.setDisableCachingForSecuredPages(Z)V
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:592)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:265)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
... 3 more
> Getting DirectBuffer OOM when sending fragmented binary message to websocket endpoint
> -------------------------------------------------------------------------------------
>
> Key: WFLY-4790
> URL: https://issues.jboss.org/browse/WFLY-4790
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Alpha3
> Reporter: Radim Hatlapatka
> Assignee: Stuart Douglas
> Priority: Critical
> Fix For: 10.0.0.Alpha6
>
>
> When sending fragmented binary message (message with message payload of length 4 * 2**20 (4M). Sent out in fragments of 64). The server throws {{java.lang.OutOfMemoryError: Direct buffer memory}} [1]
> The memory for direct buffer by default depends on the size set by -Xmx, which is in EAP 7.0.0.DR4 by default set to -Xmx512m. Increasing it just increases the time before the limit is hit (it is enough to send those messages multiple times to hit the limit again).
> I believe the issue is similar to the one for EAP 6.4: [https://bugzilla.redhat.com/show_bug.cgi?id=1223708]
> [1]
> {noformat}
> 15:10:55,463 ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError: Direct buffer memory
> at java.nio.Bits.reserveMemory(Bits.java:658)
> at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:123)
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
> at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57)
> at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55)
> at org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:143)
> at io.undertow.websockets.core.BufferedBinaryMessage$1.handleEvent(BufferedBinaryMessage.java:106)
> at io.undertow.websockets.core.BufferedBinaryMessage$1.handleEvent(BufferedBinaryMessage.java:97)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at io.undertow.server.protocol.framed.AbstractFramedStreamSourceChannel$1.run(AbstractFramedStreamSourceChannel.java:264)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:560)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:462)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-4790) Getting DirectBuffer OOM when sending fragmented binary message to websocket endpoint
by cosmin cosmin (JIRA)
[ https://issues.jboss.org/browse/WFLY-4790?page=com.atlassian.jira.plugin.... ]
cosmin cosmin commented on WFLY-4790:
-------------------------------------
Yes I did
> Getting DirectBuffer OOM when sending fragmented binary message to websocket endpoint
> -------------------------------------------------------------------------------------
>
> Key: WFLY-4790
> URL: https://issues.jboss.org/browse/WFLY-4790
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Alpha3
> Reporter: Radim Hatlapatka
> Assignee: Stuart Douglas
> Priority: Critical
> Fix For: 10.0.0.Alpha6
>
>
> When sending fragmented binary message (message with message payload of length 4 * 2**20 (4M). Sent out in fragments of 64). The server throws {{java.lang.OutOfMemoryError: Direct buffer memory}} [1]
> The memory for direct buffer by default depends on the size set by -Xmx, which is in EAP 7.0.0.DR4 by default set to -Xmx512m. Increasing it just increases the time before the limit is hit (it is enough to send those messages multiple times to hit the limit again).
> I believe the issue is similar to the one for EAP 6.4: [https://bugzilla.redhat.com/show_bug.cgi?id=1223708]
> [1]
> {noformat}
> 15:10:55,463 ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError: Direct buffer memory
> at java.nio.Bits.reserveMemory(Bits.java:658)
> at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:123)
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
> at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57)
> at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55)
> at org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:143)
> at io.undertow.websockets.core.BufferedBinaryMessage$1.handleEvent(BufferedBinaryMessage.java:106)
> at io.undertow.websockets.core.BufferedBinaryMessage$1.handleEvent(BufferedBinaryMessage.java:97)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at io.undertow.server.protocol.framed.AbstractFramedStreamSourceChannel$1.run(AbstractFramedStreamSourceChannel.java:264)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:560)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:462)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (JGRP-2195) [JGRP00012] discarded message from different cluster with JGroups Upgrade
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2195?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2195:
--------------------------------
Please don't use JIRA for questions; posting to the mailing list is preferred; JIRAs are only for bugs.
Thanks,
> [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, 10 months
[JBoss JIRA] (JGRP-2195) [JGRP00012] discarded message from different cluster with JGroups Upgrade
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2195?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2195.
----------------------------
Resolution: Rejected
> [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, 10 months
[JBoss JIRA] (JGRP-2195) [JGRP00012] discarded message from different cluster with JGroups Upgrade
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2195?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2195:
--------------------------------
Why didn't you upgrade to a more recent version of JGroups, e.g. 4.0 or at least 3.6.x?
Anyway, you should give more space between ports of different clusters: bind_ports of 34060, 34061 and 34062 with a port_range of 1 are likely to overlap. Below's a config that's better:
ClusterA:
TCP bind_port=30000, 30001, 30002 // 3 members
TCPPING: initial_hosts=xxx\[30000\] port_range=2
ClusterB:
TCP bind_port=40000, 40001, 40002 // 3 members
TCPPING: initial_hosts=xxx\[40000\] port_range=2
ClusterC:
TCP bind_port=50000, 50001, 50002 // 3 members
TCPPING: initial_hosts=xxx\[50000\] port_range=2
> [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, 10 months
[JBoss JIRA] (WFLY-8937) Management/security-realm/authentication/users integration with credential reference is not correct.
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/WFLY-8937?page=com.atlassian.jira.plugin.... ]
Hynek Švábek updated WFLY-8937:
-------------------------------
Steps to Reproduce:
* Copy cs001.jceks keystore from attachment to JBOSS_HOME/standalone/data location or update path on attached standalone.xml
* Run EAP server with standalone.xml configuration file which is attached.
* There are defined three users one uses password and others use credential store (clear-text password and store + alias)
** go to http://localhost:9990/console/App.html and use pepa/pepa123 credentials - it works (uses password attribute)
** go to http://localhost:9990/console/App.html and use hynek/hynek123 credentials - it doesn't work (uses credential-reference and store + alias)
** go to http://localhost:9990/console/App.html and use ondra/ondra123 credentials - it doesn't work (uses credential-reference and clear-text password)
* You can add there new alias to credential store like that
{code}
/subsystem=elytron/credential-store=cs001:add-alias(alias=newuseralias, secret-value=newuser123)
{code}
* and then add there new authentication user for management like that
{code}
/core-service=management/security-realm=ManagementRealm/authentication=users/user=newuser:add(credential-reference={store=cs001, alias=newuseralias})
{code}
Then you can try log in to management console http://localhost:9990/console/App.html
newuser/newuser123
was:
* Copy cs001.jceks keystore from attachment to JBOSS_HOME/standalone/data location or update path on attached standalone.xml
* Run EAP server with standalone.xml configuration file which is attached.
* There are defined two users one uses password and second one uses credential store
** go to http://localhost:9990/console/App.html and use pepa/pepa123 credentials - it works
** go to http://localhost:9990/console/App.html and use hynek/hynek123 credentials - it doesn't work
* You can add there new alias to credential store like that
{code}
/subsystem=elytron/credential-store=cs001:add-alias(alias=newuseralias, secret-value=newuser123)
{code}
* and then add there new authentication user for management like that
{code}
/core-service=management/security-realm=ManagementRealm/authentication=users/user=newuser:add(credential-reference={store=cs001, alias=newuseralias})
{code}
Then you can try log in to management console http://localhost:9990/console/App.html
newuser/newuser123
> Management/security-realm/authentication/users integration with credential reference is not correct.
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-8937
> URL: https://issues.jboss.org/browse/WFLY-8937
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> Management/security-realm/authentication/users integration with credential reference is not correct.
> When user set authentication/users instead of authentication/properties and add there user who has defined credential-reference then he is not able to log in to management console.
> It must work, please check *Steps to Reproduce* section.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months