[JBoss JIRA] (SWSQE-722) MaistraIstio project role request for Sunil/Prachi to work on Polarion PQI reports
by Matthew Mahoney (Jira)
[ https://issues.jboss.org/browse/SWSQE-722?page=com.atlassian.jira.plugin.... ]
Matthew Mahoney updated SWSQE-722:
----------------------------------
Sprint: Kiali Sprint #23 (was: Kiali Sprint #22)
> MaistraIstio project role request for Sunil/Prachi to work on Polarion PQI reports
> ----------------------------------------------------------------------------------
>
> Key: SWSQE-722
> URL: https://issues.jboss.org/browse/SWSQE-722
> Project: Kiali QE
> Issue Type: QE Task
> Reporter: Sunil Kondkar
> Assignee: Prachi Yadav
> Priority: Major
> Labels: pqi
>
> At present Sunil has read only access for MaistraIstio project.
> Below roles may be needed for the polarion project - MaistraIstio for Sunil and Prachi to be able to work on PQI reports for polarion.
> project_admin, project_user, project_approver, project_assignable, project_qe, project_useradmin
> Todo: Prachi to request through email to the person who created the polarion MaistraIstio project.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (SWSQE-640) Kiali Pipeline 3.0
by Matthew Mahoney (Jira)
[ https://issues.jboss.org/browse/SWSQE-640?page=com.atlassian.jira.plugin.... ]
Matthew Mahoney updated SWSQE-640:
----------------------------------
Sprint: Kiali Sprint #23 (was: Kiali Sprint #22)
> Kiali Pipeline 3.0
> ------------------
>
> Key: SWSQE-640
> URL: https://issues.jboss.org/browse/SWSQE-640
> Project: Kiali QE
> Issue Type: Story
> Reporter: Guilherme Baufaker Rêgo
> Assignee: Guilherme Baufaker Rêgo
> Priority: Critical
> Labels: infrastructure
>
> Since we are moving from Ansible Upstream installer ( it will be deprecated on Istio 1.1 (https://github.com/istio/istio/issues/12262), Bookinfo has been updated on Kiali Test Mesh Operator (KIALI-2520 and SWSQE-594) and we are moving to central-ci Jenkins, move to DSL jobs, I think it is a good opportunity to make a better pipeline with small number of jobs (currently we have lot of jobs which are not technically accurate anymore)
> At least these jobs need to change:
> - Nightly Jobs
> - Complex Mesh
> - Kiali Test Meshes
> - Clean Istio Resources
> - Istio Upstream
> - Kiali on Openshift
> - Istio and Kiali on Openshift
> - Maistra Job (it might need to change because the new operator based on golang)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12090) Unknown service name jboss.ejb and txn
by Flavia Rainone (Jira)
Flavia Rainone created WFLY-12090:
-------------------------------------
Summary: Unknown service name jboss.ejb and txn
Key: WFLY-12090
URL: https://issues.jboss.org/browse/WFLY-12090
Project: WildFly
Issue Type: Bug
Components: EJB, Transactions
Affects Versions: 17.0.0.Alpha1
Reporter: Flavia Rainone
Assignee: Flavia Rainone
Fix For: 17.0.0.Beta1
When EJBRemoting service is not started (it is LAZY), but XA recovery has, we could have the following sort of error:
{code}
16:51:46,785 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: WFTXN0034: Failed to acquire a connection for this operation
at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getOperationsXA(RemotingRemoteTransactionPeer.java:139)
at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.recover(RemotingRemoteTransactionPeer.java:202)
at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:201)
at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:197)
at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:634)
at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:226)
at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:171)
at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770)
at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)
Caused by: org.jboss.remoting3.ServiceOpenException: Unknown service name jboss.ejb
at org.jboss.remoting@5.0.10.Final-SNAPSHOT//org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:429)
at org.jboss.remoting@5.0.10.Final-SNAPSHOT//org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:46)
at org.jboss.xnio@3.7.2.Final-SNAPSHOT//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.jboss.xnio@3.7.2.Final-SNAPSHOT//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.jboss.xnio.nio@3.7.2.Final-SNAPSHOT//org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
at org.jboss.xnio.nio@3.7.2.Final-SNAPSHOT//org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
Suppressed: org.jboss.remoting3.ServiceOpenException: Unknown service name txn
... 6 more
{code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12090) Unknown service name jboss.ejb and txn
by Flavia Rainone (Jira)
[ https://issues.jboss.org/browse/WFLY-12090?page=com.atlassian.jira.plugin... ]
Flavia Rainone commented on WFLY-12090:
---------------------------------------
A possible solution would be making XARecoveryService dependent on EJBRemoting service, but it appears this creates a circular dependency.
> Unknown service name jboss.ejb and txn
> --------------------------------------
>
> Key: WFLY-12090
> URL: https://issues.jboss.org/browse/WFLY-12090
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Affects Versions: 17.0.0.Alpha1
> Reporter: Flavia Rainone
> Assignee: Flavia Rainone
> Priority: Major
> Fix For: 17.0.0.Beta1
>
>
> When EJBRemoting service is not started (it is LAZY), but XA recovery has, we could have the following sort of error:
> {code}
> 16:51:46,785 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: WFTXN0034: Failed to acquire a connection for this operation
> at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getOperationsXA(RemotingRemoteTransactionPeer.java:139)
> at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.recover(RemotingRemoteTransactionPeer.java:202)
> at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:201)
> at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:197)
> at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:634)
> at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:226)
> at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:171)
> at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770)
> at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)
> Caused by: org.jboss.remoting3.ServiceOpenException: Unknown service name jboss.ejb
> at org.jboss.remoting@5.0.10.Final-SNAPSHOT//org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:429)
> at org.jboss.remoting@5.0.10.Final-SNAPSHOT//org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:46)
> at org.jboss.xnio@3.7.2.Final-SNAPSHOT//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.jboss.xnio@3.7.2.Final-SNAPSHOT//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.jboss.xnio.nio@3.7.2.Final-SNAPSHOT//org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.jboss.xnio.nio@3.7.2.Final-SNAPSHOT//org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> Suppressed: org.jboss.remoting3.ServiceOpenException: Unknown service name txn
> ... 6 more
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-9631) "Failed to reinstate timer" warning is shown when creating large number of EJB timers
by Martin Weiler (Jira)
[ https://issues.jboss.org/browse/WFLY-9631?page=com.atlassian.jira.plugin.... ]
Martin Weiler commented on WFLY-9631:
-------------------------------------
Attaching a reproducer for the issue, tested on EAP 7.2.0.GA.
After removing the {{timers.remove(..)}} call in [DatabaseTimerPersistence|https://github.com/wildfly/wildfly/blob/master/e...] the WARN message is gone. Not sure if this has any adverse side-effects, eg. in a clustered environment though.
Could someone please take a look and provide input?
> "Failed to reinstate timer" warning is shown when creating large number of EJB timers
> -------------------------------------------------------------------------------------
>
> Key: WFLY-9631
> URL: https://issues.jboss.org/browse/WFLY-9631
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Environment: EAP 7.0.8.GA
> Oracle 12 c
> [Configuration of datasources|https://github.com/MarianMacik/timers-testing/blob/c7dde64d27...] - XA Datasource for jBPM - our application - and a separate XA Datasource for EJB Timers in a different schema.
> Reporter: Marian Macik
> Assignee: Michal Jurc
> Priority: Major
> Attachments: WFLY-9631-reproducer.zip
>
>
> Hi, [~manovotn],
> as we discussed before, I am creating a JIRA for an issue I experienced when testing EJB Timers with jBPM.
> What I did was that I started a large number of processes with jBPM, let's say 10 000 and more. Each process contains a timer which jBPM will create an EJB Timer for. Each timer was configured to fire at exactly the same time, e.g. 12:00 PM. During the test I got this warning displayed about 5 times for each 10 000 timers created:
> {code:java}
> WARN [org.jboss.as.ejb3] (Timer-1) WFLYEJB0161: Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' (id=09afab21-6b0f-41b0-9338-403b4a12e507) from its persistent state: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource 09afab21-6b0f-41b0-9338-403b4a12e507
> at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290)
> at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169)
> at org.jboss.as.ejb3.subsystem.deployment.TimerServiceResource.timerCreated(TimerServiceResource.java:193)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.registerTimerResource(TimerServiceImpl.java:1094)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.startTimer(TimerServiceImpl.java:767)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl$TimerRefreshListener.timerAdded(TimerServiceImpl.java:1235)
> at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence$RefreshTask.run(DatabaseTimerPersistence.java:820)
> at java.util.TimerThread.mainLoop(Timer.java:555)
> at java.util.TimerThread.run(Timer.java:505)
> {code}
> The result of these warnings was that when I had only one EAP instance to fire these timers, it wouldn't fire exactly the timers with ids that were in those warnings, e.g. if it was id=09afab21-6b0f-41b0-9338-403b4a12e507 then this timer wouldn't fire. I had waited for minutes to be sure there is another tick of a refresh interval (configured to 1 min) but nothing happened. But when I started the second EAP instance, they were immediately picked up by that instance and fired. It seems that if there is this warning on a particular instance, the instance won't pick up the timer whatsoever. They will be picked up only by some other instances if there are any. With 2 EAP instances there were warnings too, but all timers fired since I guess affected timers were picked up each time by the other instance.
> Another interesting observation is that when I configured a refresh interval to be shorter, e.g. 5 seconds, these warnings were showing up almost every 5 seconds. When I set it to 30 minutes, I didn't get warnings at all, since all timers fired earlier than a refresh occurred.
> So I think it has something to do with refresh interval.
> Can you please have a look at it? For further configuration details, check the Environment field.
> Thank you very much!
> Marian Macik
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months