[JBoss JIRA] (AG-136) Add a safe callback interface for pool events
by Luis Barreiro (Jira)
[ https://issues.redhat.com/browse/AG-136?page=com.atlassian.jira.plugin.sy... ]
Luis Barreiro updated AG-136:
-----------------------------
Description:
There is a need for a callback to intercept pool events that is safe for applications to use.
Right now the current listener interface is fine for container implementations, but should not be used by higher level applications because:
* The {{AgroalDataSourceListener}} interface was not designed with the Interceptor concept in mind. Agroal always invoke the listeners in the given order, so if there are 2 listeners with common concerns,only one of them will be effective.
* The Listener gives access to the raw {{java.sql.Connection}} and therefore any error may cause chaos on the pool (leave an invalid connection on the pool, etc.)
* Some methods on the listener are invoked by Agroal's own thread and therefore should not execute any long running task (that is not a problem in the context of this issue, but may be if we expose this interface as API)
* When running Agroal with a TransactionManager, the life-cycle of the connections can be slightly different as this is associated with the transaction. This does not map well on the current listener interface.
A new interface PoolInteceptor should be added to address this issues.
was:
There is a need for a callback to intercept pool events that is safe for applications to use.
Right now the current listener interface is fine for container implementations, but should not be used by higher level applications because:
* The ```AgroalDataSourceListener``` interface was not designed with the Interceptor concept in mind. Agroal always invoke the listeners in the given order, so if there are 2 listeners with common concerns,only one of them will be effective.
* The Listener gives access to the raw ```java.sql.Connection`` and therefore any error may cause chaos on the pool (leave an invalid connection on the pool, etc.)
* Some methods on the listener are invoked by Agroal's own thread and therefore should not execute any long running task (that is not a problem in the context of this issue, but may be if we expose this interface as API)
* When running Agroal with a TransactionManager, the life-cycle of the connections can be slightly different as this is associated with the transaction. This does not map well on the current listener interface.
> Add a safe callback interface for pool events
> ---------------------------------------------
>
> Key: AG-136
> URL: https://issues.redhat.com/browse/AG-136
> Project: Agroal
> Issue Type: Feature Request
> Components: api, pool
> Affects Versions: 1.7
> Reporter: Luis Barreiro
> Assignee: Luis Barreiro
> Priority: Major
> Fix For: 1.8
>
>
> There is a need for a callback to intercept pool events that is safe for applications to use.
> Right now the current listener interface is fine for container implementations, but should not be used by higher level applications because:
> * The {{AgroalDataSourceListener}} interface was not designed with the Interceptor concept in mind. Agroal always invoke the listeners in the given order, so if there are 2 listeners with common concerns,only one of them will be effective.
> * The Listener gives access to the raw {{java.sql.Connection}} and therefore any error may cause chaos on the pool (leave an invalid connection on the pool, etc.)
> * Some methods on the listener are invoked by Agroal's own thread and therefore should not execute any long running task (that is not a problem in the context of this issue, but may be if we expose this interface as API)
> * When running Agroal with a TransactionManager, the life-cycle of the connections can be slightly different as this is associated with the transaction. This does not map well on the current listener interface.
> A new interface PoolInteceptor should be added to address this issues.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (AG-136) Add a safe callback interface for pool events
by Luis Barreiro (Jira)
Luis Barreiro created AG-136:
--------------------------------
Summary: Add a safe callback interface for pool events
Key: AG-136
URL: https://issues.redhat.com/browse/AG-136
Project: Agroal
Issue Type: Feature Request
Components: api, pool
Affects Versions: 1.7
Reporter: Luis Barreiro
Assignee: Luis Barreiro
Fix For: 1.8
There is a need for a callback to intercept pool events that is safe for applications to use.
Right now the current listener interface is fine for container implementations, but should not be used by higher level applications because:
* The ```AgroalDataSourceListener``` interface was not designed with the Interceptor concept in mind. Agroal always invoke the listeners in the given order, so if there are 2 listeners with common concerns,only one of them will be effective.
* The Listener gives access to the raw ```java.sql.Connection`` and therefore any error may cause chaos on the pool (leave an invalid connection on the pool, etc.)
* Some methods on the listener are invoked by Agroal's own thread and therefore should not execute any long running task (that is not a problem in the context of this issue, but may be if we expose this interface as API)
* When running Agroal with a TransactionManager, the life-cycle of the connections can be slightly different as this is associated with the transaction. This does not map well on the current listener interface.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[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)
4 years
[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)
4 years
[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)
4 years
[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)
4 years
[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)
4 years