[JBoss JIRA] (WFCORE-2774) Move org.jboss.as.test.manualmode.mgmt.elytron.HttpMgmtInterfaceElytronAuthenticationTestCase to wildfly-core
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2774?page=com.atlassian.jira.plugi... ]
Petr Kremensky commented on WFCORE-2774:
----------------------------------------
[~luck3y] I see some intermittent failures in this one - see e.g. https://url.corp.redhat.com/54bd3ea
*Error Details*
{noformat}
Cannot validate host 'slave' is running
{noformat}
*Stack Trace*
{noformat}
java.lang.AssertionError: Cannot validate host 'slave' is running
at org.junit.Assert.fail(Assert.java:88)
at org.jboss.as.test.integration.domain.AbstractSlaveHCAuthenticationTestCase.readHostControllerStatus(AbstractSlaveHCAuthenticationTestCase.java:75)
at org.jboss.as.test.integration.domain.SlaveHostControllerAuthenticationTestCase.slaveWithVaultPasswordTest(SlaveHostControllerAuthenticationTestCase.java:145)
at org.jboss.as.test.integration.domain.SlaveHostControllerAuthenticationTestCase.testSlaveRegistration(SlaveHostControllerAuthenticationTestCase.java:93)
{noformat}
> Move org.jboss.as.test.manualmode.mgmt.elytron.HttpMgmtInterfaceElytronAuthenticationTestCase to wildfly-core
> -------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2774
> URL: https://issues.jboss.org/browse/WFCORE-2774
> Project: WildFly Core
> Issue Type: Sub-task
> Components: Domain Management, Security, Test Suite
> Reporter: Ken Wills
> Assignee: Ken Wills
> Fix For: 3.0.0.Beta22
>
>
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (JGRP-2172) Non-blocking flow control
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2172?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2172:
--------------------------------
I'm thinking of NB_UFC and NB_MFC: all messages are either directly sent (if we have enough credits) or queued. The NB_FC flag would not be needed. The max_queue_size (in bytes) determines how much data can be queued at any given time until a caller thread blocks.
This means that a sender cannot control the behavior for individual messages; instead the behavior is the same for all messages and is defined by the choice of flow control protocol.
> 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, 11 months
[JBoss JIRA] (ELY-1233) Elytron revise why exception stacktrace is not logged in some cases
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/ELY-1233?page=com.atlassian.jira.plugin.s... ]
Lin Gao reassigned ELY-1233:
----------------------------
Assignee: Lin Gao (was: Darran Lofthouse)
> Elytron revise why exception stacktrace is not logged in some cases
> -------------------------------------------------------------------
>
> Key: ELY-1233
> URL: https://issues.jboss.org/browse/ELY-1233
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Martin Choma
> Assignee: Lin Gao
> Priority: Critical
>
> During verification of JBEAP-9297 I have found another occurences where logging should be justified.
> In some cases not logging exception can hide original cause of problem.
> But justification is necessary if extending loggin won't introduce unnecessary logs, but it does not seems to me this should be case.
> {code}
> [mchoma@localhost wildfly-elytron]$ grep -r ".*\.debug([^\"]" --include=*.java .
> ./src/main/java/org/wildfly/security/auth/realm/FileSystemSecurityRealm.java: ElytronMessages.log.debug(e);
> ./src/main/java/org/wildfly/security/auth/realm/FileSystemSecurityRealm.java: ElytronMessages.log.debug(e);
> ./src/main/java/org/wildfly/security/auth/realm/FileSystemSecurityRealm.java: ElytronMessages.log.debug(e);
> ./src/main/java/org/wildfly/security/auth/realm/FileSystemSecurityRealm.java: ElytronMessages.log.debug(e);
> ./src/main/java/org/wildfly/security/http/util/SecurityProviderServerMechanismFactory.java: log.debug(e);
> ./src/main/java/org/wildfly/security/http/util/SecurityProviderServerMechanismFactory.java: log.debug(e);
> ./src/main/java/org/wildfly/security/http/util/ServiceLoaderServerMechanismFactory.java: log.debug(e);
> ./src/main/java/org/wildfly/security/http/util/ServiceLoaderServerMechanismFactory.java: log.debug(e);
> ./src/main/java/org/wildfly/security/sasl/util/SecurityProviderSaslClientFactory.java: log.debug(e);
> ./src/main/java/org/wildfly/security/sasl/util/SecurityProviderSaslClientFactory.java: log.debug(e);
> ./src/main/java/org/wildfly/security/sasl/util/SecurityProviderSaslServerFactory.java: log.debug(e);
> ./src/main/java/org/wildfly/security/sasl/util/SecurityProviderSaslServerFactory.java: log.debug(e);
> [mchoma@localhost wildfly-elytron]$ grep -r ".*\.trace([^\"]" --include=*.java .
> ./src/main/java/org/wildfly/security/ssl/CipherSuiteSelector.java: ElytronMessages.tls.trace(b);
> ./src/main/java/org/wildfly/security/ssl/CipherSuiteSelector.java: ElytronMessages.tls.trace(b);
> ./src/main/java/org/wildfly/security/http/impl/DigestAuthenticationMechanism.java: log.trace(e);
> {code}
> These are OK
> {code}
> ./src/main/java/org/wildfly/security/ssl/CipherSuiteSelector.java: ElytronMessages.tls.trace(b);
> ./src/main/java/org/wildfly/security/ssl/CipherSuiteSelector.java: ElytronMessages.tls.trace(b);
> {code}
> Setting to Critical priority, as this could reveal useful information during process of troubleshooting.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFCORE-2974) CLI completion after one or more spaces gives confusing result
by Chao Wang (JIRA)
Chao Wang created WFCORE-2974:
---------------------------------
Summary: CLI completion after one or more spaces gives confusing result
Key: WFCORE-2974
URL: https://issues.jboss.org/browse/WFCORE-2974
Project: WildFly Core
Issue Type: Bug
Components: CLI
Affects Versions: 3.0.0.Beta26
Reporter: Chao Wang
Priority: Minor
CLI completion after one or more spaces gives confusing result.
{noformat}
[standalone@localhost:9990 /] /sub[space]TabKey Here
above completion returns result:
[standalone@localhost:9990 /] /sub ystem=
It seems the space before TabKey is recognized as character 's'.
Go on for a second TabKey, it will not list any subsystem candidates.
{noformat}
I think the first completion is not necessary as the {{sub}} with a following space is not a valid path. It'd better stop there rather than return completion result {{/sub ystem=}}. But this is a minor case.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (ELY-1250) org.jboss.remoting3.RemotingOptions.SASL_PROTOCOL make ejb client call hang
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/ELY-1250?page=com.atlassian.jira.plugin.s... ]
Yeray Borges moved JBEAP-11630 to ELY-1250:
-------------------------------------------
Project: WildFly Elytron (was: JBoss Enterprise Application Platform)
Key: ELY-1250 (was: JBEAP-11630)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: (was: Remoting)
Affects Version/s: (was: 7.1.0.DR18)
Affects Testing: (was: Regression)
> org.jboss.remoting3.RemotingOptions.SASL_PROTOCOL make ejb client call hang
> ---------------------------------------------------------------------------
>
> Key: ELY-1250
> URL: https://issues.jboss.org/browse/ELY-1250
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Yeray Borges
> Assignee: Yeray Borges
> Priority: Blocker
>
> Until DR18 (and in 7.0 as well) we succesfully called ejb with these options.
> {code:java|title=EjbClientCode.java}
> private Properties getCtxProperties(String username, String password) {
> Properties props = new Properties();
> props.put("org.jboss.ejb.client.scoped.context", true);
> props.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
> props.put("remote.connections", "main");
> props.put("remote.connection.main.host", hostname);
> props.put("remote.connection.main.port", "8080");
> if (username != null && password != null) {
> props.put("remote.connection.main.username", username);
> props.put("remote.connection.main.password", password);
> }
> props.put("remote.connection.main.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT", "false");
> props.put("remote.connection.main.connect.options.org.jboss.remoting3.RemotingOptions.SASL_PROTOCOL", "remote");
> props.put("remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED", "false");
> return props;
> }
> {code}
> In DR18 ejb calls hangs.
> {code:title=server.log}
> 14:27:47,057 INFO [org.jboss.ejb.client] (main) EJBCLIENT000064: org.jboss.ejb.client.naming.ejb.ejbURLContextFactory is deprecated; new applications should use org.wildfly.naming.client.WildFlyInitialContextFactory instead
> 14:27:47,064 INFO [org.wildfly.naming] (main) WildFly Naming version 1.0.0.Beta15-redhat-1
> 14:27:47,076 INFO [org.wildfly.naming] (main) WFNAM00049: Usage of the legacy "remote.connections" property is deprecated; please use javax.naming.Context#PROVIDER_URL instead
> 14:27:47,088 FINER [javax.management.mbeanserver] (main) ObjectName = jboss.remoting.endpoint:name=Remoting (anonymous)-1039159201
> 14:27:47,088 FINER [javax.management.mbeanserver] (main) name = jboss.remoting.endpoint:name=Remoting (anonymous)-1039159201
> 14:27:47,088 FINER [javax.management.mbeanserver] (main) Send create notification of object jboss.remoting.endpoint:name=Remoting (anonymous)-1039159201
> 14:27:47,088 FINER [javax.management.mbeanserver] (main) JMX.mbean.registered jboss.remoting.endpoint:name=Remoting (anonymous)-1039159201
> 14:27:47,088 TRACE [org.jboss.remoting.endpoint] (main) Completed open of endpoint (anonymous) <3df04fa1>
> 14:27:47,088 TRACE [org.jboss.remoting.endpoint] (main) Allocated tick to 1 of endpoint (anonymous) <3df04fa1> (opened Connection provider for remote)
> 14:27:47,089 FINER [javax.management.mbeanserver] (main) ObjectName = jboss.remoting.handler:name=Remoting (anonymous) remote-1876700598
> 14:27:47,089 FINER [javax.management.mbeanserver] (main) name = jboss.remoting.handler:name=Remoting (anonymous) remote-1876700598
> 14:27:47,089 FINER [javax.management.mbeanserver] (main) Send create notification of object jboss.remoting.handler:name=Remoting (anonymous) remote-1876700598
> 14:27:47,089 FINER [javax.management.mbeanserver] (main) JMX.mbean.registered jboss.remoting.handler:name=Remoting (anonymous) remote-1876700598
> 14:27:47,089 TRACE [org.jboss.remoting.endpoint] (main) Adding connection provider registration named 'remote': Remoting remote connection provider 6fdc2db6 for endpoint (anonymous) <3df04fa1>
> 14:27:47,089 TRACE [org.jboss.remoting.endpoint] (main) Allocated tick to 2 of endpoint (anonymous) <3df04fa1> (opened Connection provider for remote+tls)
> 14:27:47,089 FINER [javax.management.mbeanserver] (main) ObjectName = jboss.remoting.handler:name=Remoting (anonymous) remote+tls-383127665
> 14:27:47,089 FINER [javax.management.mbeanserver] (main) name = jboss.remoting.handler:name=Remoting (anonymous) remote+tls-383127665
> 14:27:47,089 FINER [javax.management.mbeanserver] (main) Send create notification of object jboss.remoting.handler:name=Remoting (anonymous) remote+tls-383127665
> 14:27:47,089 FINER [javax.management.mbeanserver] (main) JMX.mbean.registered jboss.remoting.handler:name=Remoting (anonymous) remote+tls-383127665
> 14:27:47,089 TRACE [org.jboss.remoting.endpoint] (main) Adding connection provider registration named 'remote+tls': Remoting remote connection provider 16d61071 for endpoint (anonymous) <3df04fa1>
> 14:27:47,089 TRACE [org.jboss.remoting.endpoint] (main) Allocated tick to 3 of endpoint (anonymous) <3df04fa1> (opened Connection provider for remoting)
> 14:27:47,090 FINER [javax.management.mbeanserver] (main) ObjectName = jboss.remoting.handler:name=Remoting (anonymous) remoting-838733029
> 14:27:47,090 FINER [javax.management.mbeanserver] (main) name = jboss.remoting.handler:name=Remoting (anonymous) remoting-838733029
> 14:27:47,090 FINER [javax.management.mbeanserver] (main) Send create notification of object jboss.remoting.handler:name=Remoting (anonymous) remoting-838733029
> 14:27:47,090 FINER [javax.management.mbeanserver] (main) JMX.mbean.registered jboss.remoting.handler:name=Remoting (anonymous) remoting-838733029
> 14:27:47,090 TRACE [org.jboss.remoting.endpoint] (main) Adding connection provider registration named 'remoting': Remoting remote connection provider 31fe0ce5 for endpoint (anonymous) <3df04fa1>
> 14:27:47,090 TRACE [org.jboss.remoting.endpoint] (main) Allocated tick to 4 of endpoint (anonymous) <3df04fa1> (opened Connection provider for remote+http)
> 14:27:47,090 FINER [javax.management.mbeanserver] (main) ObjectName = jboss.remoting.handler:name=Remoting (anonymous) remote+http-1795925655
> 14:27:47,090 FINER [javax.management.mbeanserver] (main) name = jboss.remoting.handler:name=Remoting (anonymous) remote+http-1795925655
> 14:27:47,090 FINER [javax.management.mbeanserver] (main) Send create notification of object jboss.remoting.handler:name=Remoting (anonymous) remote+http-1795925655
> 14:27:47,090 FINER [javax.management.mbeanserver] (main) JMX.mbean.registered jboss.remoting.handler:name=Remoting (anonymous) remote+http-1795925655
> 14:27:47,090 TRACE [org.jboss.remoting.endpoint] (main) Adding connection provider registration named 'remote+http': Remoting remote connection provider 6b0ba697 for endpoint (anonymous) <3df04fa1>
> 14:27:47,090 TRACE [org.jboss.remoting.endpoint] (main) Allocated tick to 5 of endpoint (anonymous) <3df04fa1> (opened Connection provider for remote+https)
> 14:27:47,090 FINER [javax.management.mbeanserver] (main) ObjectName = jboss.remoting.handler:name=Remoting (anonymous) remote+https-447059608
> 14:27:47,091 FINER [javax.management.mbeanserver] (main) name = jboss.remoting.handler:name=Remoting (anonymous) remote+https-447059608
> 14:27:47,091 FINER [javax.management.mbeanserver] (main) Send create notification of object jboss.remoting.handler:name=Remoting (anonymous) remote+https-447059608
> 14:27:47,091 FINER [javax.management.mbeanserver] (main) JMX.mbean.registered jboss.remoting.handler:name=Remoting (anonymous) remote+https-447059608
> 14:27:47,091 TRACE [org.jboss.remoting.endpoint] (main) Adding connection provider registration named 'remote+https': Remoting remote connection provider 1aa59698 for endpoint (anonymous) <3df04fa1>
> 14:27:47,091 TRACE [org.jboss.remoting.endpoint] (main) Allocated tick to 6 of endpoint (anonymous) <3df04fa1> (opened Connection provider for http-remoting)
> 14:27:47,091 FINER [javax.management.mbeanserver] (main) ObjectName = jboss.remoting.handler:name=Remoting (anonymous) http-remoting-981876983
> 14:27:47,091 FINER [javax.management.mbeanserver] (main) name = jboss.remoting.handler:name=Remoting (anonymous) http-remoting-981876983
> 14:27:47,091 FINER [javax.management.mbeanserver] (main) Send create notification of object jboss.remoting.handler:name=Remoting (anonymous) http-remoting-981876983
> 14:27:47,091 FINER [javax.management.mbeanserver] (main) JMX.mbean.registered jboss.remoting.handler:name=Remoting (anonymous) http-remoting-981876983
> 14:27:47,091 TRACE [org.jboss.remoting.endpoint] (main) Adding connection provider registration named 'http-remoting': Remoting remote connection provider 3a8640f7 for endpoint (anonymous) <3df04fa1>
> 14:27:47,091 TRACE [org.jboss.remoting.endpoint] (main) Allocated tick to 7 of endpoint (anonymous) <3df04fa1> (opened Connection provider for https-remoting)
> 14:27:47,091 FINER [javax.management.mbeanserver] (main) ObjectName = jboss.remoting.handler:name=Remoting (anonymous) https-remoting-1015658596
> 14:27:47,091 FINER [javax.management.mbeanserver] (main) name = jboss.remoting.handler:name=Remoting (anonymous) https-remoting-1015658596
> 14:27:47,092 FINER [javax.management.mbeanserver] (main) Send create notification of object jboss.remoting.handler:name=Remoting (anonymous) https-remoting-1015658596
> 14:27:47,092 FINER [javax.management.mbeanserver] (main) JMX.mbean.registered jboss.remoting.handler:name=Remoting (anonymous) https-remoting-1015658596
> 14:27:47,092 TRACE [org.jboss.remoting.endpoint] (main) Adding connection provider registration named 'https-remoting': Remoting remote connection provider 3c89b864 for endpoint (anonymous) <3df04fa1>
> 14:27:47,093 TRACE [org.wildfly.security] (main) getAuthenticationConfiguration uri=remote+http://localhost.localdomain:8080, protocolDefaultPort=-1, abstractType=jndi, abstractTypeAuthority=jboss, purpose=operate, MatchRule=[], AuthenticationConfiguration=[AuthenticationConfiguration:principal=anonymous,set-host=localhost.localdomain,set-port=8080,providers-supplier=org.wildfly.security.auth.client.ElytronXmlParser$DeferredSupplier@17d816b3,sasl-mechanism-selector=(true),mechanism-properties={wildfly.sasl.local-user.quiet-auth=true}]
> 14:27:47,111 INFO [org.jboss.ejb.client] (main) JBoss EJB Client version 4.0.0.Beta27-redhat-1
> 14:27:47,176 TRACE [org.jboss.remoting.endpoint] (main) Allocated tick to 8 of endpoint (anonymous) <3df04fa1> (opened Connection to remote://localhost.localdomain:8080)
> 14:27:47,177 TRACE [org.jboss.remoting.remote] (main) Attempting to connect to "remote://localhost.localdomain:8080" with options {}
> 14:27:47,177 TRACE [org.xnio.nio.selector] (XNIO-1 I/O-1) Selected on sun.nio.ch.EPollSelectorImpl@4cb9755d
> 14:27:47,177 TRACE [org.xnio.nio] (XNIO-1 I/O-1) Running task org.xnio.nio.WorkerThread$SynchTask@51262ca9
> 14:27:47,177 TRACE [org.xnio.nio.selector] (XNIO-1 I/O-1) Beginning select on sun.nio.ch.EPollSelectorImpl@4cb9755d
> 14:27:47,177 TRACE [org.xnio.nio.selector] (XNIO-1 I/O-1) Selected on sun.nio.ch.EPollSelectorImpl@4cb9755d
> 14:27:47,177 TRACE [org.xnio.nio.selector] (XNIO-1 I/O-1) Beginning select on sun.nio.ch.EPollSelectorImpl@4cb9755d
> 14:27:47,177 TRACE [org.xnio.nio.selector] (XNIO-1 I/O-1) Selected on sun.nio.ch.EPollSelectorImpl@4cb9755d
> 14:27:47,177 TRACE [org.xnio.nio.selector] (XNIO-1 I/O-1) Selected key sun.nio.ch.SelectionKeyImpl@47d9c01 for java.nio.channels.SocketChannel[connection-pending local=/0.0.0.0:45737 remote=localhost.localdomain/127.0.0.1:8080]
> 14:27:47,177 TRACE [org.xnio.nio] (XNIO-1 I/O-1) Running task org.xnio.AbstractIoFuture$NotifierRunnable@12b137f5
> 14:27:47,179 TRACE [org.jboss.remoting.endpoint] (XNIO-1 I/O-1) Allocated tick to 9 of endpoint (anonymous) <3df04fa1> (opened org.jboss.remoting3.EndpointImpl$TrackingExecutor@4bb2dc67)
> 14:27:47,179 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Initialized connection from localhost.localdomain/127.0.0.1:8080 to /127.0.0.1:45737 with options {}
> 14:27:47,179 TRACE [org.jboss.remoting.endpoint] (XNIO-1 task-5) Resource closed count 00000008 of endpoint (anonymous) <3df04fa1> (closed org.jboss.remoting3.EndpointImpl$TrackingExecutor@4bb2dc67)
> 14:27:47,179 TRACE [org.jboss.remoting.remote] (XNIO-1 I/O-1) Setting read listener to org.jboss.remoting3.remote.ClientConnectionOpenListener$Greeting@3fe64581
> 14:27:47,179 TRACE [org.xnio.nio.selector] (XNIO-1 I/O-1) Beginning select on sun.nio.ch.EPollSelectorImpl@4cb9755d
> {code}
> It appears {{org.jboss.remoting3.RemotingOptions.SASL_PROTOCOL}} is making problems here. If I remove this ejb call is sucesfull.
> Same happens with org.wildfly.naming.client.WildFlyInitialContextFactory when protocol of PROVIDER_URL and SASL_PROTOCOL does not match.
> {code}
> private Properties getBasicCtxProperties(String timeout) {
> Properties props = new Properties();
> props.put("org.jboss.ejb.client.scoped.context", true);
> props.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
> props.put(Context.PROVIDER_URL, "http-remoting://"+hostname+":8080");
> if (timeout != null) {
> props.put("remote.connection.main.connect.timeout", timeout);
> }
> props.put("remote.connection.main.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT", "false");
> props.put("remote.connection.main.connect.options.org.jboss.remoting3.RemotingOptions.SASL_PROTOCOL", "remote");
> props.put("remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED", "false");
> return props;
> }
> {code}
> Setting to blocker:
> - it can make difficulties by migrating from legacy client configuration to new client configuration
> - in second case (non-deprecated configuration), there should be rather some sort of validaiton check, then let client hang.
> [1] https://github.com/jboss-remoting/jboss-remoting/blob/master/src/main/jav...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (JGRP-2172) Non-blocking flow control
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2172?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2172:
--------------------------------
[~rvansa] If you look at my previous comment, are you suggesting the behavior I described is *not* suitable? IMO it is; the causality between P1 and P2 is only given if P1 is blocking and P2 is only sent once P1 returns. In this case, we'll never deliver P2 before P1. Otherwise, there is no causality and then it doesn't matter in which order P1 and P2 are delivered.
Do you have an example which shows unwanted behavior?
> 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, 11 months
[JBoss JIRA] (JGRP-2172) Non-blocking flow control
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2172?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2172 at 6/19/17 1:49 AM:
---------------------------------------------------------
Expose the queue size (number of messages and/or number of bytes?)
was (Author: belaban):
Expose the queue size (buffered msgs)
> 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, 11 months