[JBoss JIRA] (WFLY-6505) CalendarBasedTimeout needs to trim whitespaces in ScheduleExpression.timezone
by Cheng Fang (JIRA)
[ https://issues.jboss.org/browse/WFLY-6505?page=com.atlassian.jira.plugin.... ]
Cheng Fang reassigned WFLY-6505:
--------------------------------
Assignee: Cheng Fang
> CalendarBasedTimeout needs to trim whitespaces in ScheduleExpression.timezone
> -----------------------------------------------------------------------------
>
> Key: WFLY-6505
> URL: https://issues.jboss.org/browse/WFLY-6505
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final
> Reporter: Cheng Fang
> Assignee: Cheng Fang
> Priority: Minor
>
> When creating a calendar-based timer with a timezone id having leading/trailiing whitespaces, the specified timezone is ignored and the system default timezone is used instead.
> Although there is a warning, users may not notice it and would still expect the requested timezone to be used.
> The logged warning:
> {code:text}
> 13:18:14,259 WARN [org.jboss.as.ejb3] (default task-42) WFLYEJB0015: Unknown timezone id:
> US/Eastern
> found in schedule expression. Ignoring it and using server's timezone: America/New_York
> {code}
> The user-provided timezone 'US/Eastern' is a valid timezone (after trimming).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (LOGTOOL-102) Remove the ToolLogger
by James Perkins (JIRA)
James Perkins created LOGTOOL-102:
-------------------------------------
Summary: Remove the ToolLogger
Key: LOGTOOL-102
URL: https://issues.jboss.org/browse/LOGTOOL-102
Project: Log Tool
Issue Type: Task
Reporter: James Perkins
Assignee: James Perkins
The {{ToolLogger}} was added to simplify logging debug messages. There is no real need for it anymore so it should be removed. The debug methods can be added as helper methods in the {{AbstractGenerator}} if needed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6505) CalendarBasedTimeout needs to trim whitespaces in ScheduleExpression.timezone
by Cheng Fang (JIRA)
[ https://issues.jboss.org/browse/WFLY-6505?page=com.atlassian.jira.plugin.... ]
Cheng Fang updated WFLY-6505:
-----------------------------
Description:
When creating a calendar-based timer with a timezone id having leading/trailiing whitespaces, the specified timezone is ignored and the system default timezone is used instead.
Although there is a warning, users may not notice it and would still expect the requested timezone to be used.
The logged warning:
{code:text}
13:18:14,259 WARN [org.jboss.as.ejb3] (default task-42) WFLYEJB0015: Unknown timezone id:
US/Eastern
found in schedule expression. Ignoring it and using server's timezone: America/New_York
{code}
The user-provided timezone 'US/Eastern' is a valid timezone (after trimming).
was:
When creating a calendar-based timer with a timezone id having leading/trailiing whitespaces, the specified timezone is ignored and the system default timezone is used instead.
Although there is a warning, users may not notice it and would still expect the requested timezone to be used.
The logged warning:
13:18:14,259 WARN [org.jboss.as.ejb3] (default task-42) WFLYEJB0015: Unknown timezone id:
US/Eastern
found in schedule expression. Ignoring it and using server's timezone: America/New_York
The user-provided timezone 'US/Eastern' is a valid timezone (after trimming).
> CalendarBasedTimeout needs to trim whitespaces in ScheduleExpression.timezone
> -----------------------------------------------------------------------------
>
> Key: WFLY-6505
> URL: https://issues.jboss.org/browse/WFLY-6505
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final
> Reporter: Cheng Fang
> Priority: Minor
>
> When creating a calendar-based timer with a timezone id having leading/trailiing whitespaces, the specified timezone is ignored and the system default timezone is used instead.
> Although there is a warning, users may not notice it and would still expect the requested timezone to be used.
> The logged warning:
> {code:text}
> 13:18:14,259 WARN [org.jboss.as.ejb3] (default task-42) WFLYEJB0015: Unknown timezone id:
> US/Eastern
> found in schedule expression. Ignoring it and using server's timezone: America/New_York
> {code}
> The user-provided timezone 'US/Eastern' is a valid timezone (after trimming).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6505) CalendarBasedTimeout needs to trim whitespaces in ScheduleExpression.timezone
by Cheng Fang (JIRA)
Cheng Fang created WFLY-6505:
--------------------------------
Summary: CalendarBasedTimeout needs to trim whitespaces in ScheduleExpression.timezone
Key: WFLY-6505
URL: https://issues.jboss.org/browse/WFLY-6505
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 10.0.0.Final
Reporter: Cheng Fang
Priority: Minor
When creating a calendar-based timer with a timezone id having leading/trailiing whitespaces, the specified timezone is ignored and the system default timezone is used instead.
Although there is a warning, users may not notice it and would still expect the requested timezone to be used.
The logged warning:
13:18:14,259 WARN [org.jboss.as.ejb3] (default task-42) WFLYEJB0015: Unknown timezone id:
US/Eastern
found in schedule expression. Ignoring it and using server's timezone: America/New_York
The user-provided timezone 'US/Eastern' is a valid timezone (after trimming).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1115) IndexOutOfBoundException when using conditional break + query
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1115?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration updated DROOLS-1115:
--------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1325403
Bugzilla Update: Perform
> IndexOutOfBoundException when using conditional break + query
> -------------------------------------------------------------
>
> Key: DROOLS-1115
> URL: https://issues.jboss.org/browse/DROOLS-1115
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.CR2
> Reporter: Massinissa BOUZIAD
> Assignee: Mario Fusco
> Priority: Blocker
> Fix For: 7.0.0.Final
>
>
> I got an java.lang.ArrayIndexOutOfBoundsException when I use conditionnal breaking and queries.
> I face this issue since 6.4.0.CR2 and not before this.
> Following the stack trace :
> java.lang.ArrayIndexOutOfBoundsException: 2
> at org.drools.core.reteoo.AbstractTerminalNode.getPathNodes(AbstractTerminalNode.java:304)
> at org.drools.core.reteoo.AbstractTerminalNode.getPathNodes(AbstractTerminalNode.java:311)
> at org.drools.core.phreak.PhreakQueryTerminalNode.checkAndTriggerQueryReevaluation(PhreakQueryTerminalNode.java:173)
> at org.drools.core.phreak.PhreakQueryTerminalNode.doLeftInserts(PhreakQueryTerminalNode.java:78)
> at org.drools.core.phreak.PhreakQueryTerminalNode.doNode(PhreakQueryTerminalNode.java:54)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:282)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:136)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:94)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1003)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1346)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1284)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1303)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1293)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1274)
> at com.darty.drools.CodicCriteriaTest.price(CodicCriteriaTest.java:53)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1115) IndexOutOfBoundException when using conditional break + query
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1115?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on DROOLS-1115:
-------------------------------------------------
Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1325403|https://bugzilla.redhat.com/show_bug.cgi?id=1325403] from NEW to ASSIGNED
> IndexOutOfBoundException when using conditional break + query
> -------------------------------------------------------------
>
> Key: DROOLS-1115
> URL: https://issues.jboss.org/browse/DROOLS-1115
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.CR2
> Reporter: Massinissa BOUZIAD
> Assignee: Mario Fusco
> Priority: Blocker
> Fix For: 7.0.0.Final
>
>
> I got an java.lang.ArrayIndexOutOfBoundsException when I use conditionnal breaking and queries.
> I face this issue since 6.4.0.CR2 and not before this.
> Following the stack trace :
> java.lang.ArrayIndexOutOfBoundsException: 2
> at org.drools.core.reteoo.AbstractTerminalNode.getPathNodes(AbstractTerminalNode.java:304)
> at org.drools.core.reteoo.AbstractTerminalNode.getPathNodes(AbstractTerminalNode.java:311)
> at org.drools.core.phreak.PhreakQueryTerminalNode.checkAndTriggerQueryReevaluation(PhreakQueryTerminalNode.java:173)
> at org.drools.core.phreak.PhreakQueryTerminalNode.doLeftInserts(PhreakQueryTerminalNode.java:78)
> at org.drools.core.phreak.PhreakQueryTerminalNode.doNode(PhreakQueryTerminalNode.java:54)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:282)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:136)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:94)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1003)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1346)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1284)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1303)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1293)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1274)
> at com.darty.drools.CodicCriteriaTest.price(CodicCriteriaTest.java:53)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[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 commented on WFLY-6498:
-------------------------------------------
[~pferraro]
Is it intended that there are two transaction managers at work here?
13:15:20,213 INFO [stdout] (default task-18) org.jboss.as.ejb3.tx.CMTTxInterceptor: processInvocation: txn manager instance : com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate@4ecb8e22
...
13:15:20,229 INFO [stdout] (default task-18) org.wildfly.clustering.ee.infinispan.InfinispanBatcher: current txn manager: org.infinispan.transaction.tm.DummyTransactionManager@7ae5a027
> 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)
10 years