[JBoss JIRA] (DROOLS-744) Rule Generation Feature Request
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-744?page=com.atlassian.jira.plugin... ]
Michael Biarnes Kiefer updated DROOLS-744:
------------------------------------------
Fix Version/s: 7.0.0.Beta2
(was: 7.0.0.Beta1)
> Rule Generation Feature Request
> -------------------------------
>
> Key: DROOLS-744
> URL: https://issues.jboss.org/browse/DROOLS-744
> Project: Drools
> Issue Type: Feature Request
> Components: core engine, kie server
> Affects Versions: 6.2.0.Final
> Reporter: Justin Holmes
> Assignee: Mario Fusco
> Fix For: 7.0.0.Beta2
>
>
> As a developer using Drools, I want a rule generation java api that supports control logic in the rule templates (e.g. for loops, if/else) and integrates with the rule workbench in order to build highly dynamic business rules driven systems.
> The initial thought process around implementation is to build two things 1) a simple way to author mvel templates in business central, the existing text editor could be used at first and 2) a simple embedded java api in it's own maven module which can checkout the git project that has the mvel template, apply a set of domain objects to the template, check in the resulting rule files to the local git repo and then push the changes back to business central. This allows us to leverage the power of the existing MVEL and JGit tech stack while pushing the complexity to a java api, where we are stronger than the workbench itself.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6498) EJBClient UserTransactions with multiple method invocations generate lock conflicts
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-6498?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-6498 at 7/7/16 9:08 AM:
-------------------------------------------------------------------
Perhaps not. All beans will be using the same Batch, and the batch will not be closed until the last release() is called, and so in theory, the work on all beans will be committed at that point. But SFSB instances may have references to the batch left uncleared.
So, with the current change (which only clears the session instance CacheContext on release if there is no transaction active), if we have one user transaction with an invocation on A and an invocation on on B and an invocation on C, then, at commit time, B and C will still have references to the common Batch in their CacheContext fields. Which is probably what we don't want.
This could be fixed by storing in the TSR, not only the Batch instance, but also the K id of the session instance of the first invocation through in the user transaction. Then in release(), rather than choose to remove or not remove the CacheContext based on whether we are in a transaction, do it based on whether or not we are in a transaction and the K id matches.
was (Author: rachmato):
Perhaps not. All beans will be using the same Batch, and the batch will not be closed until the last release() is called, and so in theory, the work on all beans will be committed at that point. But SFSB instances may have references to the batch left uncleared.
So, with the current change (which only clears the session instance CacheContext on release if there is no transaction active), if we have one user transaction with an invocation on A and an invocation on on B and an invocation on C, then, at commit time, B and C will still have references to the common Batch in their CacheContext fields. Which is probably what we don't want.
> EJBClient UserTransactions with multiple method invocations generate lock conflicts
> ------------------------------------------------------------------------------------
>
> Key: WFLY-6498
> URL: https://issues.jboss.org/browse/WFLY-6498
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Richard Achmatowicz
> Assignee: Paul Ferraro
> Fix For: 11.0.0.Alpha1
>
>
> Using the EJBClient library, we should be able to do the following from a standalone EJBClient application:
> // create a UserTransaction associated with a clustered server node X
> // make an invocation on an EJB on X
> // make an invocation on an EJB on X
> // commit the UserTransaction
> However, doing so results in this exception which occurs during processing of the second invocation:
> {noformat}
> [0m[31m11:16:22,580 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-57) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 15 seconds for key UnknownSessionID [4967684957516649565452525270575756545166695455535750486549485166] and requestor GlobalTransaction:<node-0>:120:local. Lock is held by GlobalTransaction:<node-0>:118:local
> at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.lock(DefaultLockManager.java:236)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockAndRecord(AbstractLockingInterceptor.java:190)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockKey(AbstractTxLockingInterceptor.java:192)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockOrRegisterBackupLock(AbstractTxLockingInterceptor.java:113)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataReadCommand(PessimisticLockingInterceptor.java:70)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitGetKeyValueCommand(AbstractLockingInterceptor.java:77)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:345)
> at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:330)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitReadCommand(StateTransferInterceptor.java:176)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitGetKeyValueCommand(StateTransferInterceptor.java:153)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:76)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411)
> at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:443)
> at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
> at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.findValue(InfinispanBeanFactory.java:87)
> at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.findValue(InfinispanBeanFactory.java:49)
> at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager.findBean(InfinispanBeanManager.java:244)
> at org.jboss.as.ejb3.cache.distributable.DistributableCache.get(DistributableCache.java:124)
> at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:59)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:333)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> {noformat}
> The exception does not arise if we perform only one invocation within the UserTransaction.
> This exception is repeatable.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (DROOLS-1103) FireAllRules can trigger java.util.concurrent.RejectedExecutionException from the JDKTimerService
by Juan Carlos Garcia (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1103?page=com.atlassian.jira.plugi... ]
Juan Carlos Garcia commented on DROOLS-1103:
--------------------------------------------
No i don't, just to mention my setup:
We create thousands of StatefulKnowledgeSession session per hour as each of them correspond to a gaming session between few users (besides regulars game rules, we also have timer rules to control certain aspect as timeout, disconnect, ect), so once a game if finished we received a message to close the game (if we don't get the appropriate message we have some Janitors kicking in every 5 / 10 minutes and disposing the Sessions that are still in our SessionStore (ConcurrentMap on a Singleton EJB) and haven't received events from customers) and we disposed our StatefulKnowledgeSession in order to be good citizens.
In order to mitigate that exception we are now Serializing user access, per game to the StatefulKnowledgeSession thru our own locking.
I check today and we had only one of this exception in the past 15 days (but looks little bit different). as it is coming from a timer being triggered directly and not from FireAllRules scenario.
{code}
_ThreadID=21899;_ThreadName=pool-116731-thread-1;_TimeMillis=1467642563388;_LevelValue=900;|
Unable to execute timer job!
java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@60560a44 rejected from java.util.concurrent.ScheduledThreadPoolExecutor@7671ec29[Shutting down, pool size = 1, active threads = 1, queued tasks = 0, completed tasks = 6]
at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:326)
at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:549)
at org.drools.core.time.impl.JDKTimerService.internalSchedule(JDKTimerService.java:116)
at org.drools.core.time.impl.JDKTimerService.scheduleJob(JDKTimerService.java:99)
at org.drools.core.phreak.PhreakTimerNode.scheduleTimer(PhreakTimerNode.java:307)
at org.drools.core.phreak.PhreakTimerNode.scheduleLeftTuple(PhreakTimerNode.java:230)
at org.drools.core.phreak.PhreakTimerNode.doLeftInserts(PhreakTimerNode.java:108)
at org.drools.core.phreak.PhreakTimerNode.doNode(PhreakTimerNode.java:83)
at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:400)
at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:332)
at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:166)
at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:320)
at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:293)
at org.drools.core.reteoo.BetaNode.assertObject(BetaNode.java:294)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384)
at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:145)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384)
at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:298)
at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93)
at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993)
at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:128)
at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:78)
at org.drools.core.phreak.PhreakTimerNode$TimerAction.evaluateAndFireRule(PhreakTimerNode.java:439)
at org.drools.core.phreak.PhreakTimerNode$TimerAction.execute(PhreakTimerNode.java:431)
at org.drools.core.phreak.SynchronizedPropagationList$1.execute(SynchronizedPropagationList.java:39)
at org.drools.core.common.DefaultAgenda.executeTask(DefaultAgenda.java:1355)
at org.drools.core.phreak.SynchronizedPropagationList.addEntry(SynchronizedPropagationList.java:36)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.addPropagation(StatefulKnowledgeSessionImpl.java:1989)
at org.drools.core.phreak.PhreakTimerNode$TimerNodeJob.execute(PhreakTimerNode.java:375)
at org.drools.core.time.SelfRemovalJob.execute(SelfRemovalJob.java:34)
at org.drools.core.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:69)
at org.drools.core.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:30)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
> FireAllRules can trigger java.util.concurrent.RejectedExecutionException from the JDKTimerService
> -------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1103
> URL: https://issues.jboss.org/browse/DROOLS-1103
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final
> Reporter: Juan Carlos Garcia
> Assignee: Mario Fusco
>
> Under very rare circumstance we have found the following exception *java.util.concurrent.RejectedExecutionException* in our production log.
> Our guess is that the Drools Session is on its way to be dispose, while a new incoming request is in the middle of a fireAllRules operation (race condition).
> I will try to provide a reproducible testcase for this.
> {code}
> Caused by: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@3e896443 rejected from java.util.concurrent.ScheduledThreadPoolExecutor@71cc2f4c[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
> at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
> at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:326)
> at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:549)
> at org.drools.core.time.impl.JDKTimerService.internalSchedule(JDKTimerService.java:118)
> at org.drools.core.time.impl.JDKTimerService.scheduleJob(JDKTimerService.java:101)
> at org.drools.core.phreak.PhreakTimerNode.scheduleTimer(PhreakTimerNode.java:304)
> at org.drools.core.phreak.PhreakTimerNode.scheduleLeftTuple(PhreakTimerNode.java:233)
> at org.drools.core.phreak.PhreakTimerNode.doLeftUpdates(PhreakTimerNode.java:131)
> at org.drools.core.phreak.PhreakTimerNode.doNode(PhreakTimerNode.java:65)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:357)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:161)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:116)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:67)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:935)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1200)
> at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:957)
> at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:936)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:260)
> at XXXXXX.XXXXX.XXXXX.processEventDrools(EventProcessorImpl.java:128)
> at XXXXXX.XXXXX.XXXXX.processEvent(EventProcessorImpl.java:101)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1639) Causing the process to terminate before subsystems are processed prevents management depending on subsystem provided capabilities.
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1639?page=com.atlassian.jira.plugi... ]
David Lloyd commented on WFCORE-1639:
-------------------------------------
I think we have good architectural reasons for reverting this behavior as well. Treating subsystems and the primary model identically is a closer match to the future management model design.
> Causing the process to terminate before subsystems are processed prevents management depending on subsystem provided capabilities.
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1639
> URL: https://issues.jboss.org/browse/WFCORE-1639
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Brian Stansberry
> Priority: Blocker
> Labels: affects_elytron
> Fix For: 3.0.0.Alpha4
>
>
> I am raising this immediately as a Blocker as the changes made for WFCORE-307 effectively prevent us from referencing Elytron supplied capabilities to secure the management interfaces.
> https://github.com/wildfly/wildfly-core/commit/13d8f51b79c8b976ec7a5489c9...
> I think at this point it would be easier to revert WFCORE-307 and re-evaluate.
> To provide consistency we have all been working along the path where Elytron can be configured using a subsystem and used in all modes of the server, this was even a big motivation for Kabir's work bringing subsystems to host controllers.
> We could take the view that only subsystems can depend on subsystems but I think we would quickly reach the point where we discuss moving management into a subsystem which would immediately obsolete the changes for WFCORE-307 - this move is something that has been talked about a number of times already.
> This will need discussion but as an alternative idea for the original issue reported in WFCORE-307, how about adding the ability to flag a select few capabilities as crtitical / core and those will always cause a failure in this first boot if their requirements are not satisfied.
> Also I think WFCORE-307 may only be a partial solution, if we are really saying the server can only run if it is manageable there is still the possibility that at stage RUNTIME the services will fail to start.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6808) DistributableSession validate method throw misleading exception message
by Mathieu Lachance (JIRA)
[ https://issues.jboss.org/browse/WFLY-6808?page=com.atlassian.jira.plugin.... ]
Mathieu Lachance updated WFLY-6808:
-----------------------------------
Description:
In DistributableSession the validate method is getting called for any underlying undertow session access to make sure we are not touching an already invalidated session (which totally make sense):
{code}
public class DistributableSession implements io.undertow.server.session.Session {
private static void validate(Session<LocalSessionContext> session) {
if (!session.isValid()) {
throw UndertowMessages.MESSAGES.sessionNotFound(session.getId());
}
}
}
{code}
The problem though is the exception message that is thrown is really misleading because in reality the session actually exists but is currently invalid and/or getting invalidated. This can happen especially when running in optimistic mode where we can have many differents threads accessing the very same session.
I would recommend we do instead:
{code}
if (!session.isValid()) {
throw UndertowMessages.MESSAGES.sessionAlreadyInvalidated();
}
{code}
or even better:
{code}
if (!session.isValid()) {
throw UndertowMessages.MESSAGES.sessionAlreadyInvalidated(session.getId());
}
{code}
but it will require also a change in Undertow to actually template/parametize the sessionAlreadyInvalidated message.
Thanks,
was:
In DistributableSession the validate method is getting called for any underlying undertow session access to make sure we are not touching an already invalidated session (which totally make sense):
{code}
public class DistributableSession implements io.undertow.server.session.Session {
// These mechanisms can auto-reauthenticate and thus use local context (instead of replicating)
private static final Set<String> AUTO_REAUTHENTICATING_MECHANISMS = new HashSet<>(Arrays.asList(HttpServletRequest.BASIC_AUTH, HttpServletRequest.DIGEST_AUTH, HttpServletRequest.CLIENT_CERT_AUTH));
private static void validate(Session<LocalSessionContext> session) {
if (!session.isValid()) {
throw UndertowMessages.MESSAGES.sessionNotFound(session.getId());
}
}
}
{code}
The problem though is the exception message that is thrown is really misleading because in reality the session actually exists but is currently invalid and/or getting invalidated. This can happen especially when running in optimistic mode where we can have many differents threads accessing the very same session.
I would recommend we do instead:
{code}
if (!session.isValid()) {
throw UndertowMessages.MESSAGES.sessionAlreadyInvalidated();
}
{code}
or even better:
{code}
if (!session.isValid()) {
throw UndertowMessages.MESSAGES.sessionAlreadyInvalidated(session.getId());
}
{code}
but it will require also a change in Undertow to actually template/parametize the sessionAlreadyInvalidated message.
Thanks,
> DistributableSession validate method throw misleading exception message
> -----------------------------------------------------------------------
>
> Key: WFLY-6808
> URL: https://issues.jboss.org/browse/WFLY-6808
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Mathieu Lachance
> Assignee: Paul Ferraro
>
> In DistributableSession the validate method is getting called for any underlying undertow session access to make sure we are not touching an already invalidated session (which totally make sense):
> {code}
> public class DistributableSession implements io.undertow.server.session.Session {
> private static void validate(Session<LocalSessionContext> session) {
> if (!session.isValid()) {
> throw UndertowMessages.MESSAGES.sessionNotFound(session.getId());
> }
> }
> }
> {code}
> The problem though is the exception message that is thrown is really misleading because in reality the session actually exists but is currently invalid and/or getting invalidated. This can happen especially when running in optimistic mode where we can have many differents threads accessing the very same session.
> I would recommend we do instead:
> {code}
> if (!session.isValid()) {
> throw UndertowMessages.MESSAGES.sessionAlreadyInvalidated();
> }
> {code}
> or even better:
> {code}
> if (!session.isValid()) {
> throw UndertowMessages.MESSAGES.sessionAlreadyInvalidated(session.getId());
> }
> {code}
> but it will require also a change in Undertow to actually template/parametize the sessionAlreadyInvalidated message.
> Thanks,
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6808) DistributableSession validate method throw misleading exception message
by Mathieu Lachance (JIRA)
Mathieu Lachance created WFLY-6808:
--------------------------------------
Summary: DistributableSession validate method throw misleading exception message
Key: WFLY-6808
URL: https://issues.jboss.org/browse/WFLY-6808
Project: WildFly
Issue Type: Enhancement
Components: Clustering
Affects Versions: 10.0.0.Final
Reporter: Mathieu Lachance
Assignee: Paul Ferraro
In DistributableSession the validate method is getting called for any underlying undertow session access to make sure we are not touching an already invalidated session (which totally make sense):
{code}
public class DistributableSession implements io.undertow.server.session.Session {
// These mechanisms can auto-reauthenticate and thus use local context (instead of replicating)
private static final Set<String> AUTO_REAUTHENTICATING_MECHANISMS = new HashSet<>(Arrays.asList(HttpServletRequest.BASIC_AUTH, HttpServletRequest.DIGEST_AUTH, HttpServletRequest.CLIENT_CERT_AUTH));
private static void validate(Session<LocalSessionContext> session) {
if (!session.isValid()) {
throw UndertowMessages.MESSAGES.sessionNotFound(session.getId());
}
}
}
{code}
The problem though is the exception message that is thrown is really misleading because in reality the session actually exists but is currently invalid and/or getting invalidated. This can happen especially when running in optimistic mode where we can have many differents threads accessing the very same session.
I would recommend we do instead:
{code}
if (!session.isValid()) {
throw UndertowMessages.MESSAGES.sessionAlreadyInvalidated();
}
{code}
or even better:
{code}
if (!session.isValid()) {
throw UndertowMessages.MESSAGES.sessionAlreadyInvalidated(session.getId());
}
{code}
but it will require also a change in Undertow to actually template/parametize the sessionAlreadyInvalidated message.
Thanks,
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6200) connection-url is required even when not used
by Rich DiCroce (JIRA)
[ https://issues.jboss.org/browse/WFLY-6200?page=com.atlassian.jira.plugin.... ]
Rich DiCroce commented on WFLY-6200:
------------------------------------
No, it is not correct that connection-url is mandatory. You simply need to define the host and port as connection properties instead. Read the comments on WFLY-6157 and consult your JDBC driver's documentation for more info.
> connection-url is required even when not used
> ---------------------------------------------
>
> Key: WFLY-6200
> URL: https://issues.jboss.org/browse/WFLY-6200
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 10.0.0.Final
> Reporter: Rich DiCroce
> Assignee: Lin Gao
>
> Per the comments on WFLY-6157 and WFLY-6198, connection-url is ignored in a datasource if datasource-class is defined. However, connection-url is currently mandatory. If it is not present, WildFly fails to start:
> {noformat}
> 09:51:18,216 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 8) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "datasources"),
> ("data-source" => "GamingPortalDS")
> ]) - failure description: "WFLYCTL0155: connection-url may not be null"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6807) XA Datasource wizard does not add <xa-datasource-class> element in configuration when using deployed JDBC driver
by Anthony Vanelverdinghe (JIRA)
Anthony Vanelverdinghe created WFLY-6807:
--------------------------------------------
Summary: XA Datasource wizard does not add <xa-datasource-class> element in configuration when using deployed JDBC driver
Key: WFLY-6807
URL: https://issues.jboss.org/browse/WFLY-6807
Project: WildFly
Issue Type: Bug
Components: Web Console
Affects Versions: 10.0.0.Final
Reporter: Anthony Vanelverdinghe
Assignee: Harald Pehl
When creating an Oracle XA Datasource using the wizard in the Administration Console, and specifying a JDBC driver which was uploaded as a new deployment, the wizard does not add the element <xa-datasource-class> in the datasource configuration, which causes Test Connection to fail with: "WFLYJCA0040: failed to invoke operation: WFLYJCA0047: Connection is not valid", and the stack trace below.
The wizard ought to either ask to provide the class name, or inspect the .jar to find it by itself (I'd assume most JDBC drivers come with at most 1 implementation of javax.sql.XADataSource).
11:24:01,853 ERROR [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000906: Error during crash recovery: java:/XAOracleDS (IJ0310
84: Unable to create connection): javax.resource.ResourceException: IJ031084: Unable to create connection
at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.getXAManagedConnection(XAManagedConnectionFactory.java:509)
at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory$1$1.run(XAManagedConnectionFactory.java:395)
at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory$1$1.run(XAManagedConnectionFactory.java:392)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory$1.run(XAManagedConnectionFactory.java:391)
at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory$1.run(XAManagedConnectionFactory.java:388)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.createManagedConnection(XAManagedConnectionFactory.java:387)
at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.open(XAResourceRecoveryImpl.java:355)
at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.getXAResources(XAResourceRecoveryImpl.java:193)
at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:519)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:185)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:747)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:375)
Caused by: javax.resource.ResourceException: IJ031101: XADataSourceClass is undefined
at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.getXADataSource(XAManagedConnectionFactory.java:621)
at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.getXAManagedConnection(XAManagedConnectionFactory.java:492)
... 15 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1639) Causing the process to terminate before subsystems are processed prevents management depending on subsystem provided capabilities.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1639?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-1639:
------------------------------------------
For Elytron development we are temporarily reverting the original commit to get us back up and running again: -
https://github.com/wildfly-security-incubator/wildfly-core/tree/WFCORE-1639
> Causing the process to terminate before subsystems are processed prevents management depending on subsystem provided capabilities.
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1639
> URL: https://issues.jboss.org/browse/WFCORE-1639
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Brian Stansberry
> Priority: Blocker
> Labels: affects_elytron
> Fix For: 3.0.0.Alpha4
>
>
> I am raising this immediately as a Blocker as the changes made for WFCORE-307 effectively prevent us from referencing Elytron supplied capabilities to secure the management interfaces.
> https://github.com/wildfly/wildfly-core/commit/13d8f51b79c8b976ec7a5489c9...
> I think at this point it would be easier to revert WFCORE-307 and re-evaluate.
> To provide consistency we have all been working along the path where Elytron can be configured using a subsystem and used in all modes of the server, this was even a big motivation for Kabir's work bringing subsystems to host controllers.
> We could take the view that only subsystems can depend on subsystems but I think we would quickly reach the point where we discuss moving management into a subsystem which would immediately obsolete the changes for WFCORE-307 - this move is something that has been talked about a number of times already.
> This will need discussion but as an alternative idea for the original issue reported in WFCORE-307, how about adding the ability to flag a select few capabilities as crtitical / core and those will always cause a failure in this first boot if their requirements are not satisfied.
> Also I think WFCORE-307 may only be a partial solution, if we are really saying the server can only run if it is manageable there is still the possibility that at stage RUNTIME the services will fail to start.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months