[JBoss JIRA] (WFCORE-4896) Support iteration over filtered cli query
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFCORE-4896?page=com.atlassian.jira.plug... ]
Brian Stansberry updated WFCORE-4896:
-------------------------------------
Issue Type: Feature Request (was: Enhancement)
> Support iteration over filtered cli query
> -----------------------------------------
>
> Key: WFCORE-4896
> URL: https://issues.redhat.com/browse/WFCORE-4896
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI, Management
> Reporter: Georg Tsakumagos
> Assignee: Jean Francois Denise
> Priority: Major
>
> It would be usefull to iterate over filtered queries in cli. I need to spare the only alowed level of if expression for the control flow inside the loop. I like to update all profiles containing elytron subsystem and to spare out all inherited profiles which include the base profiles.
> {code:java|title=CLI query example}
> for profile in /profile=*:query(select=[name], where=[includes=undefined])
> echo $profile
> done
> {code}
> {code:JSON|title=actual result}
> {"address" => [("profile" => "default")],"outcome" => "success","result" => {"name" => "default"}}
> {"address" => [("profile" => "ha")],"outcome" => "success","result" => {"name" => "ha"}}
> {"address" => [("profile" => "full")],"outcome" => "success","result" => {"name" => "full"}}
> {"address" => [("profile" => "full-ha")],"outcome" => "success","result" => {"name" => "full-ha"}}
> {"address" => [("profile" => "load-balancer")],"outcome" => "success","result" => {"name" => "load-balancer"}}
> {code}
> {code:java|title=desired result}
> default
> full
> full-ha
> gfi
> ha
> load-balancer
> {code}
> Maybe it would be a solution to extend the operation extend read-children-names by an property where to apply a filter.
> {code:JSON|title=extend read-children-names}
> for profile in /:read-children-names(child-type=profile,where=[includes=undefined])
> echo $profile
> done
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (WFLY-13316) MicroProfile OpenTracing integration requires scope request
by Emmanuel Hugonnet (Jira)
Emmanuel Hugonnet created WFLY-13316:
----------------------------------------
Summary: MicroProfile OpenTracing integration requires scope request
Key: WFLY-13316
URL: https://issues.redhat.com/browse/WFLY-13316
Project: WildFly
Issue Type: Bug
Components: MP OpenTracing
Affects Versions: 19.0.0.Final
Reporter: Emmanuel Hugonnet
Assignee: Emmanuel Hugonnet
MicroProfile integration is using a ServletContext which requires requestScope to be active. When trying the MP Rest Client tck with WildFly this requirement creates the following failure:
org.jboss.weld.contexts.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped
at org.jboss.weld.core@3.1.3.Final//org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:647)
at org.jboss.weld.core@3.1.3.Final//org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:89)
at org.jboss.weld.core@3.1.3.Final//org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
at org.jboss.weld.core@3.1.3.Final//org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:87)
at org.jboss.weld.core@3.1.3.Final//org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:105)
at org.jboss.weld.core(a)3.1.3.Final//org.jboss.weldx.servlet.ServletContext$$Proxy$_$$_WeldClientProxy.getAttribute(Unknown Source)
at org.wildfly.microprofile.opentracing-smallrye@20.0.0.Beta1-SNAPSHOT//org.wildfly.microprofile.opentracing.smallrye.TracerProducer.getTracer(TracerProducer.java:43)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (WFCORE-4896) Support iteration over filtered cli query
by Georg Tsakumagos (Jira)
[ https://issues.redhat.com/browse/WFCORE-4896?page=com.atlassian.jira.plug... ]
Georg Tsakumagos updated WFCORE-4896:
-------------------------------------
Description:
It would be usefull to iterate over filtered queries in cli. I need to spare the only alowed level of if expression for the control flow inside the loop. I like to update all profiles containing elytron subsystem and to spare out all inherited profiles which include the base profiles.
{code:java|title=CLI query example}
for profile in /profile=*:query(select=[name], where=[includes=undefined])
echo $profile
done
{code}
{code:JSON|title=actual result}
{"address" => [("profile" => "default")],"outcome" => "success","result" => {"name" => "default"}}
{"address" => [("profile" => "ha")],"outcome" => "success","result" => {"name" => "ha"}}
{"address" => [("profile" => "full")],"outcome" => "success","result" => {"name" => "full"}}
{"address" => [("profile" => "full-ha")],"outcome" => "success","result" => {"name" => "full-ha"}}
{"address" => [("profile" => "load-balancer")],"outcome" => "success","result" => {"name" => "load-balancer"}}
{code}
{code:java|title=desired result}
default
full
full-ha
gfi
ha
load-balancer
{code}
Maybe it would be a solution to extend the operation extend read-children-names by an property where to apply a filter.
{code:JSON|title=extend read-children-names}
for profile in /:read-children-names(child-type=profile,where=[includes=undefined])
echo $profile
done
{code}
was:
It would be usefull to iterate over filtered queries in cli. I need to spare the only alowed level of if expression for the control foll inside the loop. I like to update all profiles containing elytron subsystem and to spare out all inherited profiles which include the base profiles.
{code:java|title=CLI query example}
for profile in /profile=*:query(select=[name], where=[includes=undefined])
echo $profile
done
{code}
{code:JSON|title=actual result}
{"address" => [("profile" => "default")],"outcome" => "success","result" => {"name" => "default"}}
{"address" => [("profile" => "ha")],"outcome" => "success","result" => {"name" => "ha"}}
{"address" => [("profile" => "full")],"outcome" => "success","result" => {"name" => "full"}}
{"address" => [("profile" => "full-ha")],"outcome" => "success","result" => {"name" => "full-ha"}}
{"address" => [("profile" => "load-balancer")],"outcome" => "success","result" => {"name" => "load-balancer"}}
{code}
{code:java|title=desired result}
default
full
full-ha
gfi
ha
load-balancer
{code}
Maybe it would be a solution to extend the operation extend read-children-names by an property where to apply a filter.
{code:JSON|title=extend read-children-names}
for profile in /:read-children-names(child-type=profile,where=[includes=undefined])
echo $profile
done
{code}
> Support iteration over filtered cli query
> -----------------------------------------
>
> Key: WFCORE-4896
> URL: https://issues.redhat.com/browse/WFCORE-4896
> Project: WildFly Core
> Issue Type: Enhancement
> Components: CLI, Management
> Reporter: Georg Tsakumagos
> Assignee: Jean Francois Denise
> Priority: Major
>
> It would be usefull to iterate over filtered queries in cli. I need to spare the only alowed level of if expression for the control flow inside the loop. I like to update all profiles containing elytron subsystem and to spare out all inherited profiles which include the base profiles.
> {code:java|title=CLI query example}
> for profile in /profile=*:query(select=[name], where=[includes=undefined])
> echo $profile
> done
> {code}
> {code:JSON|title=actual result}
> {"address" => [("profile" => "default")],"outcome" => "success","result" => {"name" => "default"}}
> {"address" => [("profile" => "ha")],"outcome" => "success","result" => {"name" => "ha"}}
> {"address" => [("profile" => "full")],"outcome" => "success","result" => {"name" => "full"}}
> {"address" => [("profile" => "full-ha")],"outcome" => "success","result" => {"name" => "full-ha"}}
> {"address" => [("profile" => "load-balancer")],"outcome" => "success","result" => {"name" => "load-balancer"}}
> {code}
> {code:java|title=desired result}
> default
> full
> full-ha
> gfi
> ha
> load-balancer
> {code}
> Maybe it would be a solution to extend the operation extend read-children-names by an property where to apply a filter.
> {code:JSON|title=extend read-children-names}
> for profile in /:read-children-names(child-type=profile,where=[includes=undefined])
> echo $profile
> done
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (WFLY-12171) EJB Client requires FilePermission for ejb-xa-recovery with security manager enabled
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFLY-12171?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFLY-12171:
--------------------------------------
[~rchakrab] I don't actually know. I created a [branch|https://github.com/jamezp/wildfly/tree/WFLY-12172-revert] with a revert commit and one of the tests passed. I started a [CI job|https://ci.wildfly.org/buildConfiguration/WF_MasterSecurityManager/19...] on that branch with the security manager enabled.
> EJB Client requires FilePermission for ejb-xa-recovery with security manager enabled
> ------------------------------------------------------------------------------------
>
> Key: WFLY-12171
> URL: https://issues.redhat.com/browse/WFLY-12171
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Security Manager
> Reporter: James Perkins
> Assignee: Ivo Studensky
> Priority: Major
>
> The EJB client requires write permissions for the {{$JBOSS_HOME/standalone/data/ejb-xa-recovery}} as well as all files in that directory.
> {code:title=Example Policy}
> grant {
> permission java.io.FilePermission
> "/opt/wildfly/standalone/data/ejb-xa-recovery", "read-write";
> permission java.io.FilePermission
> "/opt/wildfly/standalone/data/ejb-xa-recovery/-", "read-write";
> };
> {code}
> {code:title=Example Exception}
> javax.ejb.EJBException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/store/work/tc-work/bb15431f347cd651/testsuite/integration/basic/target/wildfly/standalone/data/ejb-xa-recovery" "write")" in code source "(vfs:/content/ejb-client-descriptor-test-with-jboss-ejb-client_1_2_xml.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.ejb-client-descriptor-test-with-jboss-ejb-client_1_2_xml.jar" from Service Module Loader")
> at org.jboss.ejb.protocol.remote.EJBClientChannel.processInvocation(EJBClientChannel.java:488)
> at org.jboss.ejb.protocol.remote.RemoteEJBReceiver$1.lambda$handleDone$0(RemoteEJBReceiver.java:91)
> at org.xnio.FinishedIoFuture.addNotifier(FinishedIoFuture.java:79)
> at org.jboss.ejb.protocol.remote.RemoteEJBReceiver$1.handleDone(RemoteEJBReceiver.java:76)
> at org.jboss.ejb.protocol.remote.RemoteEJBReceiver$1.handleDone(RemoteEJBReceiver.java:74)
> at org.xnio.IoFuture$HandlingNotifier.notify(IoFuture.java:208)
> at org.xnio.AbstractIoFuture$NotifierRunnable.run(AbstractIoFuture.java:720)
> at org.xnio.IoUtils$2.execute(IoUtils.java:71)
> at org.xnio.AbstractIoFuture.runNotifier(AbstractIoFuture.java:693)
> at org.xnio.AbstractIoFuture$CompleteState.withNotifier(AbstractIoFuture.java:132)
> at org.xnio.AbstractIoFuture.addNotifier(AbstractIoFuture.java:570)
> at org.jboss.ejb.protocol.remote.RemoteEJBReceiver.processInvocation(RemoteEJBReceiver.java:130)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:491)
> at org.jboss.ejb.protocol.remote.RemotingEJBClientInterceptor.handleInvocation(RemotingEJBClientInterceptor.java:51)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:506)
> at org.jboss.ejb.client.TransactionPostDiscoveryInterceptor.handleInvocation(TransactionPostDiscoveryInterceptor.java:70)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:506)
> at org.jboss.ejb.client.DiscoveryEJBClientInterceptor.handleInvocation(DiscoveryEJBClientInterceptor.java:110)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:506)
> at org.jboss.ejb.client.NamingEJBClientInterceptor.handleInvocation(NamingEJBClientInterceptor.java:67)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:506)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:205)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:506)
> at org.wildfly.common.context.Contextual.runExConsumer(Contextual.java:203)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequestInitial(EJBClientInvocationContext.java:333)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:187)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:125)
> at com.sun.proxy.$Proxy283.twoSecondEcho(Unknown Source)
> at org.jboss.as.test.integration.ejb.client.descriptor.EchoBean.twoSecondEcho(EchoBean.java:62)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:79)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:89)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:102)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:237)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:362)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:144)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:618)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:406)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:591)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:572)
> at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:205)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/store/work/tc-work/bb15431f347cd651/testsuite/integration/basic/target/wildfly/standalone/data/ejb-xa-recovery" "write")" in code source "(vfs:/content/ejb-client-descriptor-test-with-jboss-ejb-client_1_2_xml.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.ejb-client-descriptor-test-with-jboss-ejb-client_1_2_xml.jar" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:294)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:191)
> at java.lang.SecurityManager.checkWrite(SecurityManager.java:979)
> at org.wildfly.security.manager.WildFlySecurityManager.checkWrite(WildFlySecurityManager.java:377)
> at java.io.File.mkdir(File.java:1311)
> at org.wildfly.transaction.client.provider.jboss.FileSystemXAResourceRegistry$XAResourceRegistryFile.<init>(FileSystemXAResourceRegistry.java:207)
> at org.wildfly.transaction.client.provider.jboss.FileSystemXAResourceRegistry.getXAResourceRegistryFile(FileSystemXAResourceRegistry.java:121)
> at org.wildfly.transaction.client.provider.jboss.JBossLocalTransactionProvider.getXAResourceRegistry(JBossLocalTransactionProvider.java:160)
> at org.wildfly.transaction.client.XAOutflowedResources.getOrEnlist(XAOutflowedResources.java:57)
> at org.wildfly.transaction.client.RemoteTransactionContext.outflowTransaction(RemoteTransactionContext.java:222)
> at org.jboss.ejb.protocol.remote.EJBClientChannel.writeTransaction(EJBClientChannel.java:586)
> at org.jboss.ejb.protocol.remote.EJBClientChannel.processInvocation(EJBClientChannel.java:384)
> ... 96 more
> {code}
> Full chat conversion: https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers/to...
> {quote}
> David Lloyd: the notifier is running in the same thread because the response was available quickly enough
> David Lloyd: when that happens you get the permission exception because the test class doesn't have the filesystem permissions
> David Lloyd: the easy fix would be to grant that perm to the test
> David Lloyd: slightly more elegant would be to introduce a new permission that would grant the ability to outflow transactions and grant that permission, and use a doPrivileged inside the outflow code
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (JGRP-2462) TransferQueueBundler: drop messages if queue is full
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2462?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2462:
--------------------------------
Unit test is {{RED_Test}}
> TransferQueueBundler: drop messages if queue is full
> ----------------------------------------------------
>
> Key: JGRP-2462
> URL: https://issues.redhat.com/browse/JGRP-2462
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.2.2, 5.0.0.Alpha4
>
>
> When a bundler (like {{TransferQueueBundler}}) has a full queue, the senders will block.
> This can happen for example when the TCP {{send}} blocks due to a full send-window.
> Retransmission requests and responses compound the problem when the TQB's queue is full.
> Therefore, in addition to blocking, we should add an option to _drop_ packets when the queue is full. Investigate whether we could use some priority based scheme, which drops non-important messages first.
> Also investigate whether senders can selectively be unblocked when the queue is full, to either drop or add their messages. This could be done for example by removing elements from the queue, using the aformentioned filter.
> Look at random early detection )\[1\]) for inspiration.
> \[1\] https://en.wikipedia.org/wiki/Random_early_detection
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (JGRP-2462) TransferQueueBundler: drop messages if queue is full
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2462?page=com.atlassian.jira.plugin... ]
Bela Ban resolved JGRP-2462.
----------------------------
Resolution: Done
> TransferQueueBundler: drop messages if queue is full
> ----------------------------------------------------
>
> Key: JGRP-2462
> URL: https://issues.redhat.com/browse/JGRP-2462
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.2.2, 5.0.0.Alpha4
>
>
> When a bundler (like {{TransferQueueBundler}}) has a full queue, the senders will block.
> This can happen for example when the TCP {{send}} blocks due to a full send-window.
> Retransmission requests and responses compound the problem when the TQB's queue is full.
> Therefore, in addition to blocking, we should add an option to _drop_ packets when the queue is full. Investigate whether we could use some priority based scheme, which drops non-important messages first.
> Also investigate whether senders can selectively be unblocked when the queue is full, to either drop or add their messages. This could be done for example by removing elements from the queue, using the aformentioned filter.
> Look at random early detection )\[1\]) for inspiration.
> \[1\] https://en.wikipedia.org/wiki/Random_early_detection
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months