[JBoss JIRA] (DROOLS-1247) ForceEagerActivationOption may cause a recursive segment initialization
by Mario Fusco (JIRA)
Mario Fusco created DROOLS-1247:
-----------------------------------
Summary: ForceEagerActivationOption may cause a recursive segment initialization
Key: DROOLS-1247
URL: https://issues.jboss.org/browse/DROOLS-1247
Project: Drools
Issue Type: Bug
Components: core engine
Reporter: Mario Fusco
Assignee: Mario Fusco
Priority: Blocker
ForceEagerActivationOption may cause a recursive segments initialization resulting in an infinite recursive linked list of segment memories like: smem1 -> smem2 -> smem1 -> ... When this happens the segments evaluation makes the engine to fall in an endless loop.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (JGRP-2095) FILE_PING rewrites files too often
by Dennis Reed (JIRA)
[ https://issues.jboss.org/browse/JGRP-2095?page=com.atlassian.jira.plugin.... ]
Dennis Reed commented on JGRP-2095:
-----------------------------------
Suggested fix:
remove writeToFile call from fetchClusterMembers
add a writeToFile call sometime during startup. (has to be after Event.SET_LOCAL_ADDRESS for local_addr, and after Event.CONNECT* for group_addr)
> FILE_PING rewrites files too often
> ----------------------------------
>
> Key: JGRP-2095
> URL: https://issues.jboss.org/browse/JGRP-2095
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Reporter: Dennis Reed
> Assignee: Bela Ban
>
> FILE_PING.fetchClusterMembers writes its own data to file on every call.
> If there is an issue finding a cluster member's address, fetchClusterMembers can be called very frequently by TP's GET_PHYSICAL_ADDRESS calls.
> This can cause problems because while that file is being (unnecessarily) overwritten, any readers will see an empty or corrupt file. If it's bad enough JGRP-1448 is not sufficient to handle it, and readers will end up thinking the file is stale and delete it (even while it's still in progress of being written). That missing file can then cascade the problem, with other nodes not being able to find this member's address, and triggering the same problem again.
> There is already a scheduled task to rewrite the file occasionally, so rewriting it on every fetchClusterMembers call is not needed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (JGRP-2095) FILE_PING rewrites files too often
by Dennis Reed (JIRA)
[ https://issues.jboss.org/browse/JGRP-2095?page=com.atlassian.jira.plugin.... ]
Dennis Reed commented on JGRP-2095:
-----------------------------------
Does not affect 3.5.0 or later, because JGRP-1841 completely changed how FILE_PING works (to a single file managed by the coord).
> FILE_PING rewrites files too often
> ----------------------------------
>
> Key: JGRP-2095
> URL: https://issues.jboss.org/browse/JGRP-2095
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Reporter: Dennis Reed
> Assignee: Bela Ban
>
> FILE_PING.fetchClusterMembers writes its own data to file on every call.
> If there is an issue finding a cluster member's address, fetchClusterMembers can be called very frequently by TP's GET_PHYSICAL_ADDRESS calls.
> This can cause problems because while that file is being (unnecessarily) overwritten, any readers will see an empty or corrupt file. If it's bad enough JGRP-1448 is not sufficient to handle it, and readers will end up thinking the file is stale and delete it (even while it's still in progress of being written). That missing file can then cascade the problem, with other nodes not being able to find this member's address, and triggering the same problem again.
> There is already a scheduled task to rewrite the file occasionally, so rewriting it on every fetchClusterMembers call is not needed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (JGRP-2095) FILE_PING rewrites files too often
by Dennis Reed (JIRA)
Dennis Reed created JGRP-2095:
---------------------------------
Summary: FILE_PING rewrites files too often
Key: JGRP-2095
URL: https://issues.jboss.org/browse/JGRP-2095
Project: JGroups
Issue Type: Bug
Affects Versions: 3.2.13
Reporter: Dennis Reed
Assignee: Bela Ban
FILE_PING.fetchClusterMembers writes its own data to file on every call.
If there is an issue finding a cluster member's address, fetchClusterMembers can be called very frequently by TP's GET_PHYSICAL_ADDRESS calls.
This can cause problems because while that file is being (unnecessarily) overwritten, any readers will see an empty or corrupt file. If it's bad enough JGRP-1448 is not sufficient to handle it, and readers will end up thinking the file is stale and delete it (even while it's still in progress of being written). That missing file can then cascade the problem, with other nodes not being able to find this member's address, and triggering the same problem again.
There is already a scheduled task to rewrite the file occasionally, so rewriting it on every fetchClusterMembers call is not needed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFCORE-1695) Echo tab completion suggests variables without $ prefix
by Martin Schvarcbacher (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1695?page=com.atlassian.jira.plugi... ]
Martin Schvarcbacher moved JBEAP-5547 to WFCORE-1695:
-----------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1695 (was: JBEAP-5547)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: CLI
(was: CLI)
Affects Version/s: (was: 7.1.0.DR2)
> Echo tab completion suggests variables without $ prefix
> -------------------------------------------------------
>
> Key: WFCORE-1695
> URL: https://issues.jboss.org/browse/WFCORE-1695
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Martin Schvarcbacher
> Assignee: Alexey Loubyansky
> Priority: Minor
>
> *Description:*
> echo command prints all variables in tab auto-complete even without typing $ prefix
> This duplicates functionality of 'set' with no arguments.
> *Steps to reproduce*
> {code:bash}
> [disconnected /] set myvar1=value1
> [disconnected /] set myvar2=value2
> [disconnected /] set
> myvar1=value1
> myvar2=value2
> {code}
> *Actual*
> {code:bash}
> [disconnected /] echo <TAB>
> --help myvar1 myvar2 #should not suggest variables
> [disconnected /] echo $<TAB>myvar<TAB> #expected, auto-completes with $prefix
> myvar1 myvar2
> [disconnected /] echo myvar<TAB> #autocompletes variable without $prefix
> myvar1 myvar2
> {code}
> *Expected*
> {code:bash}
> [disconnected /] echo <TAB>
> --help
> [disconnected /] echo $<TAB>myvar<TAB>
> myvar1 myvar2
> [disconnected /] echo myvar<TAB> #does not suggest anything
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFLY-6920) Enhance behavior of transaction propagation called over IIOP to not start 2PC when called ejb creates own new transaction
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-6920?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka moved JBEAP-5546 to WFLY-6920:
----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6920 (was: JBEAP-5546)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: EJB
IIOP
(was: EJB)
(was: IIOP)
Affects Version/s: 10.1.0.CR1
(was: 7.1.0.DR1)
> Enhance behavior of transaction propagation called over IIOP to not start 2PC when called ejb creates own new transaction
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6920
> URL: https://issues.jboss.org/browse/WFLY-6920
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB, IIOP
> Affects Versions: 10.1.0.CR1
> Reporter: Ondra Chaloupka
> Assignee: Tomasz Adamski
> Priority: Minor
>
> Based on discussion at jira JBEAP-5126 (https://issues.jboss.org/browse/JBEAP-5126?focusedCommentId=13271878#comm...) there could be a good enhancement for transaction propagated over ejb called over iiop to not start 2PC process when the called ejb creates its own new transaction ({{TransactionAttributeType.REQUIRES_NEW}}).
> Quoting Tom's comment here
> {quote}
> Yeah, its expected to be this way for JTS as the context is propagated
> over. It could be possible to register an enhancement in the iiop
> subsystem to remove the context from the thread if the EJB does not
> require a propagated transaction.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFLY-6918) Unnecessary NoSuchMethodException during JSF app deployment
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/WFLY-6918?page=com.atlassian.jira.plugin.... ]
Tomas Remes updated WFLY-6918:
------------------------------
Description:
When you turn on TRACE logging for {{javax.enterprise.resource}} then you can notice following exception during JSF app deployment:
{noformat}
[javax.enterprise.resource.webcontainer.jsf.application] (ServerService Thread Pool -- 69) java.lang.NoSuchMethodException: org.jboss.as.jsf.injection.JandexAnnotationProvider.<init>(javax.servlet.ServletContext, com.sun.faces.spi.AnnotationProvider): java.lang.NoSuchMethodException: org.jboss.as.jsf.injection.JandexAnnotationProvider.<init>(javax.servlet.ServletContext, com.sun.faces.spi.AnnotationProvider)
at java.lang.Class.getConstructor0(Class.java:3082)
at java.lang.Class.getDeclaredConstructor(Class.java:2178)
at com.sun.faces.spi.ServiceFactoryUtils.getProviderFromEntry(ServiceFactory.java:83)
at com.sun.faces.spi.AnnotationProviderFactory.createAnnotationProvider(AnnotationProviderFactory.java:70)
at com.sun.faces.config.ConfigManager$AnnotationScanTask.<init>(ConfigManager.java:931)
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:385)
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:227)
at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187)
at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:200)
at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:171)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:234)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
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)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{noformat}
Problem is that {{org.jboss.as.jsf.injection.JandexAnnotationProvider}} doesn't have corresponding constructor (with two params - javax.servlet.ServletContext, com.sun.faces.spi.AnnotationProvider)
was:
When you turn on FINE logging for {{javax.enterprise.resource}} then you can notice following exception during JSF app deployment:
{noformat}
[javax.enterprise.resource.webcontainer.jsf.application] (ServerService Thread Pool -- 69) java.lang.NoSuchMethodException: org.jboss.as.jsf.injection.JandexAnnotationProvider.<init>(javax.servlet.ServletContext, com.sun.faces.spi.AnnotationProvider): java.lang.NoSuchMethodException: org.jboss.as.jsf.injection.JandexAnnotationProvider.<init>(javax.servlet.ServletContext, com.sun.faces.spi.AnnotationProvider)
at java.lang.Class.getConstructor0(Class.java:3082)
at java.lang.Class.getDeclaredConstructor(Class.java:2178)
at com.sun.faces.spi.ServiceFactoryUtils.getProviderFromEntry(ServiceFactory.java:83)
at com.sun.faces.spi.AnnotationProviderFactory.createAnnotationProvider(AnnotationProviderFactory.java:70)
at com.sun.faces.config.ConfigManager$AnnotationScanTask.<init>(ConfigManager.java:931)
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:385)
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:227)
at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187)
at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:200)
at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:171)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:234)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
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)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{noformat}
Problem is that {{org.jboss.as.jsf.injection.JandexAnnotationProvider}} doesn't have corresponding constructor (with two params - javax.servlet.ServletContext, com.sun.faces.spi.AnnotationProvider)
> Unnecessary NoSuchMethodException during JSF app deployment
> ------------------------------------------------------------
>
> Key: WFLY-6918
> URL: https://issues.jboss.org/browse/WFLY-6918
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 10.0.0.Final, 10.1.0.CR1
> Environment: it's same at current master
> Reporter: Tomas Remes
> Assignee: Farah Juma
> Priority: Minor
>
> When you turn on TRACE logging for {{javax.enterprise.resource}} then you can notice following exception during JSF app deployment:
> {noformat}
> [javax.enterprise.resource.webcontainer.jsf.application] (ServerService Thread Pool -- 69) java.lang.NoSuchMethodException: org.jboss.as.jsf.injection.JandexAnnotationProvider.<init>(javax.servlet.ServletContext, com.sun.faces.spi.AnnotationProvider): java.lang.NoSuchMethodException: org.jboss.as.jsf.injection.JandexAnnotationProvider.<init>(javax.servlet.ServletContext, com.sun.faces.spi.AnnotationProvider)
> at java.lang.Class.getConstructor0(Class.java:3082)
> at java.lang.Class.getDeclaredConstructor(Class.java:2178)
> at com.sun.faces.spi.ServiceFactoryUtils.getProviderFromEntry(ServiceFactory.java:83)
> at com.sun.faces.spi.AnnotationProviderFactory.createAnnotationProvider(AnnotationProviderFactory.java:70)
> at com.sun.faces.config.ConfigManager$AnnotationScanTask.<init>(ConfigManager.java:931)
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:385)
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:227)
> at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:200)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:171)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:234)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}
> Problem is that {{org.jboss.as.jsf.injection.JandexAnnotationProvider}} doesn't have corresponding constructor (with two params - javax.servlet.ServletContext, com.sun.faces.spi.AnnotationProvider)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFLY-6919) Nested Call of EJBs from one call of client from frontend works with @TransactionAttribute(REQUIRES_NEW)
by Serg Jakean19019 (JIRA)
Serg Jakean19019 created WFLY-6919:
--------------------------------------
Summary: Nested Call of EJBs from one call of client from frontend works with @TransactionAttribute(REQUIRES_NEW)
Key: WFLY-6919
URL: https://issues.jboss.org/browse/WFLY-6919
Project: WildFly
Issue Type: Bug
Components: EJB, Transactions
Affects Versions: 9.0.1.Final
Environment: Java 8
Reporter: Serg Jakean19019
Assignee: Tom Jenkinson
Case:
- client calls ejb1 through frontend
- ejb1 (stateless) process and saves some info
- ejb1 calls method ejb2 (stateless)
- ejb2 access saved info by ejb1 and saves something too
if Method of ejb2 has Annotation @TransactionAttribute(REQUIRES_NEW) than it works. In other case there is error. For example: javax.ejb.EJBTransactionRolledbackException: WFLYJPA0060: Transaction is required to perform this operation (either use a transaction or extended persistence context.
Ejbs are injected simply (@Inject) in other Ejbs
These calls must be one transaction to tell the truth. What is right solution and way? Or is there any problem in Transaction Management in Wildfly?
Sorry if it is no Wildfly issue and concerns discussion in forum.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months