[JBoss JIRA] (WFLY-11489) SFSB not sticky on a single cluster node when clustering of the bean is disabled
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-11489?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz edited comment on WFLY-11489 at 2/15/19 8:00 AM:
---------------------------------------------------------------------
> Not sure why this was set to resolved, as PR was not yet merged.
[~pferraro] My error, thanks for correcting.
> SFSB not sticky on a single cluster node when clustering of the bean is disabled
> --------------------------------------------------------------------------------
>
> Key: WFLY-11489
> URL: https://issues.jboss.org/browse/WFLY-11489
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Remoting
> Affects Versions: 15.0.0.Final
> Environment: A clustered environment with 2 nodes. Both nodes started with an unmodified {{standalone-ha.xml}} configuration (see _Steps to Reproduce_)
> This issue happens on 15.0.0.Final and was tested as well as on current head (sha: 372697282dccefd0b9df48e6aa4dcb69e1c4b40f).
> Reporter: Jörg Bäsner
> Assignee: Richard Achmatowicz
> Priority: Major
> Fix For: 16.0.0.CR1
>
> Attachments: reproducer.zip
>
>
> In case a stateful session bean is annotated with:
> {{@Stateful(passivationCapable=false)}}
> then the serialization is *disabled* and thus the bean is only available on a single cluster node.
> When a client now calls two different methods on this stateful bean it intermittently ends up on different cluster nodes, resulting in the following Exception:
> {code}
> ERROR [org.jboss.as.ejb3.invocation] (default task-2) WFLYEJB0034: EJB Invocation failed on component TestSessionEJB for method public abstract void test.ITestSession.method2(java.lang.String,java.lang.String) throws javax.ejb.EJBException,java.rmi.RemoteException: javax.ejb.NoSuchEJBException: WFLYEJB0168: Could not find EJB with id UUIDSessionID [4b0f4a27-40ba-411b-8852-0108a5ec64f4]
> at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:55)
> 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.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: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:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (SWSQE-594) Jenkins Jobs Hung
by Filip Brychta (Jira)
[ https://issues.jboss.org/browse/SWSQE-594?page=com.atlassian.jira.plugin.... ]
Filip Brychta commented on SWSQE-594:
-------------------------------------
It happened again after one day even with increased max token age (maybe it was using the old token and after next restart it would get token with longer max age). To be sure I downgraded the plugin. We can upgrade when the fix mentioned in previous comment is ready.
> Jenkins Jobs Hung
> -----------------
>
> Key: SWSQE-594
> URL: https://issues.jboss.org/browse/SWSQE-594
> Project: Kiali QE
> Issue Type: Bug
> Reporter: Matt Mahoney
> Assignee: Filip Brychta
> Priority: Major
> Attachments: image-2019-02-11-16-35-41-783.png
>
>
> Jenkins jobs hung in the following state:
> !image-2019-02-11-16-35-41-783.png|thumbnail!
> After nearly 30 min, restarting the Jenkins service cleared the issue and the jobs ran fine.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-11716) Deployment Fails with @Transactional in Passivating Scope Bean
by Matej Novotny (Jira)
[ https://issues.jboss.org/browse/WFLY-11716?page=com.atlassian.jira.plugin... ]
Matej Novotny commented on WFLY-11716:
--------------------------------------
This seems like a Narayana bug.
Related issue is JBTM-3044 where {{JNDIBean}} was introduced and is programatically added as a bean representation of {{TransactionManager}}.
{{TransactionManager}} is then injected into [interceptor base class|https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/cdi/class...] which makes up for the exception you are seeing. CDI spec covers that bit [here|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#passivation_validation].
{{JNDIBean}} can be made passivation capable by implementing [{{PassivationCapable}} interface|https://github.com/cdi-spec/cdi/blob/master/api/src/main/java/j...] ([as per specification|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#passivatio...])
> Deployment Fails with @Transactional in Passivating Scope Bean
> --------------------------------------------------------------
>
> Key: WFLY-11716
> URL: https://issues.jboss.org/browse/WFLY-11716
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 16.0.0.Beta1
> Environment: Java 8, Ubuntu Xenial
> Reporter: Cody Lerum
> Assignee: Brian Stansberry
> Priority: Major
> Attachments: jsf-npe.zip
>
>
> On Wildfly 16.0.0.Beta1 deployment fails
> {code}
> org.jboss.weld.exceptions.UnserializableDependencyException: WELD-001477: The bean Managed Bean [class co.cfly.oss.lerg.rateCenter.inventoryRequest.InventoryRequestView] with qualifiers [@Default @Any @Named] declares a passivating scope but has a(n) Interceptor [class com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired intercepts @Transactional] with a non-passivation-capable dependency com.arjuna.ats.jta.cdi.JNDIBean@12e2cb9f
> at org.jboss.weld.bootstrap.Validator.validateInterceptorDecoratorInjectionPointPassivationCapable(Validator.java:480)
> at org.jboss.weld.bootstrap.Validator.validateInterceptors(Validator.java:225)
> at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:175)
> at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:526)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:64)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:62)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-11716) Deployment Fails with @Transactional in Passivating Scope Bean
by Matej Novotny (Jira)
[ https://issues.jboss.org/browse/WFLY-11716?page=com.atlassian.jira.plugin... ]
Matej Novotny updated WFLY-11716:
---------------------------------
Component/s: CDI / Weld
Transactions
> Deployment Fails with @Transactional in Passivating Scope Bean
> --------------------------------------------------------------
>
> Key: WFLY-11716
> URL: https://issues.jboss.org/browse/WFLY-11716
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Transactions
> Affects Versions: 16.0.0.Beta1
> Environment: Java 8, Ubuntu Xenial
> Reporter: Cody Lerum
> Assignee: Brian Stansberry
> Priority: Major
> Attachments: jsf-npe.zip
>
>
> On Wildfly 16.0.0.Beta1 deployment fails
> {code}
> org.jboss.weld.exceptions.UnserializableDependencyException: WELD-001477: The bean Managed Bean [class co.cfly.oss.lerg.rateCenter.inventoryRequest.InventoryRequestView] with qualifiers [@Default @Any @Named] declares a passivating scope but has a(n) Interceptor [class com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired intercepts @Transactional] with a non-passivation-capable dependency com.arjuna.ats.jta.cdi.JNDIBean@12e2cb9f
> at org.jboss.weld.bootstrap.Validator.validateInterceptorDecoratorInjectionPointPassivationCapable(Validator.java:480)
> at org.jboss.weld.bootstrap.Validator.validateInterceptors(Validator.java:225)
> at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:175)
> at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:526)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:64)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:62)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (ELY-1745) The AvailableRealmsCallback should not result in a NPE if there is no mechanism configuration.
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/ELY-1745?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse commented on ELY-1745:
---------------------------------------
In my case it was the Netty example this happened in although that should not be too different from the Jetty one.
> The AvailableRealmsCallback should not result in a NPE if there is no mechanism configuration.
> ----------------------------------------------------------------------------------------------
>
> Key: ELY-1745
> URL: https://issues.jboss.org/browse/ELY-1745
> Project: WildFly Elytron
> Issue Type: Bug
> Components: API / SPI
> Reporter: Darran Lofthouse
> Assignee: Justin Cook
> Priority: Major
> Fix For: 1.8.0.CR3
>
>
> The NPE is due to the following code: -
> {noformat}
> } else if (callback instanceof AvailableRealmsCallback) {
> Collection<String> names = stateRef.get().getMechanismConfiguration().getMechanismRealmNames();
> if (log.isTraceEnabled()) {
> log.tracef("Handling AvailableRealmsCallback: realms = [%s]", String.join(", ", names));
> }
> if (! names.isEmpty()) {
> ((AvailableRealmsCallback) callback).setRealmNames(names.toArray(new String[names.size()]));
> }
> handleOne(callbacks, idx + 1);
> {noformat}
> If mechanism configuration is mandatory this should report an appropriate error, if not it should fallback to specifying an empty list.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (DROOLS-1781) Investigate possible replacement of findbugs-maven-plugin with spotbugs-maven-plugin
by Martin Cimbalek (Jira)
[ https://issues.jboss.org/browse/DROOLS-1781?page=com.atlassian.jira.plugi... ]
Martin Cimbalek commented on DROOLS-1781:
-----------------------------------------
Hello,
May I asko what is current status of this issue, please? There's been a lot of changes everywhere last weeks.
> Investigate possible replacement of findbugs-maven-plugin with spotbugs-maven-plugin
> ------------------------------------------------------------------------------------
>
> Key: DROOLS-1781
> URL: https://issues.jboss.org/browse/DROOLS-1781
> Project: Drools
> Issue Type: Task
> Components: build
> Affects Versions: 7.4.1.Final
> Reporter: Petr Široký
> Assignee: Michael Biarnes Kiefer
> Priority: Major
> Labels: java9
>
> SpotBugs is a successor of FingBugs and as such uses different groupId + artifactId for maven plugin. It should also be compatible with Java 9 (at least in the latest versions). We need to investigate it the switch is painless and if so, do it. Otherwise we need to figure out what the blockers are and slowly start to fix them as FindBugs itself won't bet any more updates it seems and so won't be Java 9 compatible.
> *How to migrate*
> * Replace
> {code}
> <groupId>org.codehaus.mojo</groupId>
> <artifactId>findbugs-maven-plugin</artifactId>
> {code}
> by
> {code}
> <groupId>com.github.spotbugs</groupId>
> <artifactId>spotbugs-maven-plugin</artifactId>
> {code}
> * Look for all "findbugs" and replace it by "spotbugs"
> ** Except for anything related to the findbugs annotations dependency that some dependencies drag in or exclude. Leave that one alone!
> ** For example, change findbugs-check -> spotbugs-check, ...
> * Merge this PR if it hasn't been merged already: https://github.com/kiegroup/optaplanner-wb/pull/320
> * Then you only need to adjust the following repo's: build-boostrap, drools, optaplanner and kie-wb-distributions.
> ** See https://github.com/search?q=org%3Akiegroup+findbugs-maven-plugin&type=Code
> ** Ignore contributed experiments, that repo is dead
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months