[JBoss JIRA] (DROOLS-4372) DMN Editor Data type usability study: design assets
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-4372?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton commented on DROOLS-4372:
-------------------------------------------
[~aglass][~sarahjane][~karreiro] I added Marvel click-thrus for each Activity, on the now modified test study plan at: https://docs.google.com/document/d/1XZrOn3OtonzMeGirOuaVHeM8vAiACvW_hFuK4...
Please review the click-thrus and let me know if tweaks are needed. There have been some additional design changes.
*Please note in Activity 3 there are two paths to add a row within a nested section that are in place in the prototype (contextual menu & add then drag.)
> DMN Editor Data type usability study: design assets
> ---------------------------------------------------
>
> Key: DROOLS-4372
> URL: https://issues.jboss.org/browse/DROOLS-4372
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Environment: Version 7.4
> Reporter: Elizabeth Clayton
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: UX, UXTeam, Usability, drools-tools
>
> Description:
> * Create a study plan outline.
> * Review usability study materials.
> * Create a click-thru wireframe prototype for a lightweight usability study to test the ease of use in viewing, creating, editing and deleting data types, particularly structured data types.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 4 months
[JBoss JIRA] (SWSQE-854) Increase code coverage above 80% (REST tests)
by Filip Brychta (Jira)
[ https://issues.jboss.org/browse/SWSQE-854?page=com.atlassian.jira.plugin.... ]
Filip Brychta commented on SWSQE-854:
-------------------------------------
Yes, I will add details when it's simple enough to run it by everyone. It still needs some tweaks to get the coverage. Will add it tomorrow.
> Increase code coverage above 80% (REST tests)
> ---------------------------------------------
>
> Key: SWSQE-854
> URL: https://issues.jboss.org/browse/SWSQE-854
> Project: Kiali QE
> Issue Type: Story
> Reporter: Filip Brychta
> Priority: Major
> Labels: automation
>
> There will be sub task for each package which is not covered at least by 80%
> For each sub task you can:
> * add new tests to increase coverage above 80%
> * add new tests to increase coverage below 80% with comment why it's not possible to achieve 80%
> * close the sub task with comment why it's not possible to cover it by tests so it should be excluded from the coverage report
> TODO: add description how to check code coverage
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 4 months
[JBoss JIRA] (LOGMGR-246) Wildfly 16 incorrect working log zip rotator
by James Perkins (Jira)
[ https://issues.jboss.org/browse/LOGMGR-246?page=com.atlassian.jira.plugin... ]
James Perkins resolved LOGMGR-246.
----------------------------------
Resolution: Done
That part was resolved in LOGMGR-256. The fix will be in WildFly 18. Sorry for the inconvenience.
> Wildfly 16 incorrect working log zip rotator
> --------------------------------------------
>
> Key: LOGMGR-246
> URL: https://issues.jboss.org/browse/LOGMGR-246
> Project: JBoss Log Manager
> Issue Type: Bug
> Components: core
> Environment: Windows,
> Oracle JDK 8
> Reporter: Igor Dmitriev
> Assignee: James Perkins
> Priority: Critical
> Fix For: 1.5.10.Final, 2.0.12.Final, 2.2.0.Final, 3.0.0.Final, 2.1.11.Final
>
>
> My logging profile configuration is:
> 1)
> {code:xml}
> <periodic-size-rotating-file-handler name="FILE" rotate-on-boot="false" autoflush="true">
> <level name="ALL"/>
> <file relative-to="jboss.server.log.dir" path="corp.log"/>
> <rotate-size value="300k"/>
> <max-backup-index value="10000"/>
> <suffix value=".yyyy-MM-dd.zip"/>
> <append value="true"/>
> </periodic-size-rotating-file-handler>
> {code}
> File corp.log increase it size permanently, even after new corp.log.yyyy-MM-dd.N.zip file created. Due it, each .zip archive contain same corp.log with maximum current size.
> 2)
> {code:xml}
> <periodic-size-rotating-file-handler name="FILE2" rotate-on-boot="true" autoflush="true">
> <level name="ALL"/>
> <file relative-to="jboss.server.log.dir" path="corp.log"/>
> <rotate-size value="300k"/>
> <max-backup-index value="10000"/>
> <suffix value=".yyyy-MM-dd.zip"/>
> <append value="false"/>
> </periodic-size-rotating-file-handler>
> {code}
> All work as expected, except each time corp.log reach 300k, appear pair .zip files with same content?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 4 months
[JBoss JIRA] (SWSQE-854) Increase code coverage above 80% (REST tests)
by Matthew Mahoney (Jira)
[ https://issues.jboss.org/browse/SWSQE-854?page=com.atlassian.jira.plugin.... ]
Matthew Mahoney commented on SWSQE-854:
---------------------------------------
[~fbrychta] is there a Cobertura Coverage Report for the above?
> Increase code coverage above 80% (REST tests)
> ---------------------------------------------
>
> Key: SWSQE-854
> URL: https://issues.jboss.org/browse/SWSQE-854
> Project: Kiali QE
> Issue Type: Story
> Reporter: Filip Brychta
> Priority: Major
> Labels: automation
>
> There will be sub task for each package which is not covered at least by 80%
> For each sub task you can:
> * add new tests to increase coverage above 80%
> * add new tests to increase coverage below 80% with comment why it's not possible to achieve 80%
> * close the sub task with comment why it's not possible to cover it by tests so it should be excluded from the coverage report
> TODO: add description how to check code coverage
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 4 months
[JBoss JIRA] (WFLY-11937) WF transaction client returns XAER_RMERR during abort after server with subordinate transaction fails
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-11937?page=com.atlassian.jira.plugin... ]
Ondrej Chaloupka updated WFLY-11937:
------------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-transaction-client/pull/74, https://github.com/wildfly/wildfly/pull/12365 (was: https://github.com/wildfly/wildfly-transaction-client/pull/74)
> WF transaction client returns XAER_RMERR during abort after server with subordinate transaction fails
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-11937
> URL: https://issues.jboss.org/browse/WFLY-11937
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 10.1.0.Final, 14.0.0.Final, 15.0.0.Final, 16.0.0.Final
> Reporter: Ivan Straka
> Assignee: Ondrej Chaloupka
> Priority: Major
>
> *Scenario*
> # Server1 enlists dummy XA resource and make JPA call
> # Server1 calls a EJB on Server2
> # Server2 enlists dummy XA resource and make JPA call
> # Server2 is halted at the beginning of dummy XA resource
> # Transaction is supposed to be rolled back
> We can see following lines in the log of Server1
> {code:java}
> 2019-04-02 21:22:41,707 TRACE [com.arjuna.ats.jta] (default task-2) XAResourceRecord.topLevelAbort for XAResourceRecord < resource:Subordinate XAResource at http-remoting://127.0.0.1:8180, txid:< formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff7f000001:-70ba203e:5ca3d272:2f, node_name=TWkA, branch_uid=0:ffff7f000001:-70ba203e:5ca3d272:35, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@531d7d94 >, record id=0:ffff7f000001:-70ba203e:5ca3d272:36
> 2019-04-02 21:22:41,708 WARN [com.arjuna.ats.jta] (default task-2) ARJUNA016045: attempted rollback of < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff7f000001:-70ba203e:5ca3d272:2f, node_name=TWkA, branch_uid=0:ffff7f000001:-70ba203e:5ca3d272:35, subordinatenodename=null, eis_name=unknown eis name > (Subordinate XAResource at http-remoting://127.0.0.1:8180) failed with exception code XAException.XAER_RMERR: javax.transaction.xa.XAException: WFTXN0026: Failed to send protocol message to remote peer
> at org.wildfly.transaction.client.provider.remoting.TransactionClientChannel.rollback(TransactionClientChannel.java:98)
> at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer$1.rollback(RemotingRemoteTransactionPeer.java:149)
> at org.wildfly.transaction.client.SubordinateXAResource.rollback(SubordinateXAResource.java:174)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelAbort(XAResourceRecord.java:362)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3023)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3002)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1981)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1519)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:96)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1288)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89)
> at org.wildfly.transaction.client.LocalTransaction.commitAndDissociate(LocalTransaction.java:75)
> at org.wildfly.transaction.client.ContextTransactionManager.commit(ContextTransactionManager.java:71)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:88)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:261)
> 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.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:80)
> 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:565)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:546)
> at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:197)
> 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: org.jboss.remoting3.NotOpenException: Writes closed
> at org.jboss.remoting3.remote.RemoteConnectionChannel.openOutboundMessage(RemoteConnectionChannel.java:106)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.writeMessage(RemoteConnectionChannel.java:291)
> at org.jboss.remoting3.util.MessageTracker.openMessage(MessageTracker.java:64)
> at org.jboss.remoting3.util.InvocationTracker.allocateMessage(InvocationTracker.java:189)
> at org.jboss.remoting3.util.InvocationTracker.allocateMessage(InvocationTracker.java:205)
> at org.wildfly.transaction.client.provider.remoting.TransactionClientChannel.rollback(TransactionClientChannel.java:91)
> ... 58 more
> 2019-04-02 21:22:41,709 WARN [com.arjuna.ats.arjuna] (default task-2) ARJUNA012089: Top-level abort of action 0:ffff7f000001:-70ba203e:5ca3d272:2f received heuristic decision: TwoPhaseOutcome.HEURISTIC_HAZARD
> {code}
> *TLDR;*
> Server2 is halted and Server1 gets XAER_RMERR. During abort/rollback Server2 is still down and Server1 gets XAER_RMERR. Result of this is that the transaction is in heuristic state and not rolled back.
> Based of the XA spec (http://pubs.opengroup.org/onlinepubs/009680699/toc.pdf) the XAER_RMFAIL (or XA_RETRY) is the correct XAException error code.
> _XAER_RMERR_
> a resource manager error occurred in the transaction branch
> _XAER_RMFAIL_
> resource manager unavailable
> _XA_RETRY_
> routine returned with no effect and may be reissued
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 4 months