[JBoss JIRA] (WFLY-11770) Force offline mode for provisioning
by Alexey Loubyansky (Jira)
[ https://issues.jboss.org/browse/WFLY-11770?page=com.atlassian.jira.plugin... ]
Alexey Loubyansky updated WFLY-11770:
-------------------------------------
Summary: Force offline mode for provisioning (was: Do not generate example configurations in build module)
> Force offline mode for provisioning
> -----------------------------------
>
> Key: WFLY-11770
> URL: https://issues.jboss.org/browse/WFLY-11770
> Project: WildFly
> Issue Type: Task
> Components: Build System
> Reporter: Alexey Loubyansky
> Assignee: Alexey Loubyansky
> Priority: Major
>
> Purely to reduce the build time. Provisioning of the example configurations on average doubles the time (e.g. provisioning build dist with example configs took on my laptop 16 sec and 7 sec w/o the example configs).
> NOTE: the legacy build does include example configs, which means this will show up in diff comparing the two. If this is not desirable then this issue should be rejected.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11771) Tracing: The active span is null in the EJB interceptor for the MDB onMessage
by Andrej Petras (Jira)
Andrej Petras created WFLY-11771:
------------------------------------
Summary: Tracing: The active span is null in the EJB interceptor for the MDB onMessage
Key: WFLY-11771
URL: https://issues.jboss.org/browse/WFLY-11771
Project: WildFly
Issue Type: Bug
Components: EJB, MP OpenTracing
Affects Versions: 15.0.1.Final
Reporter: Andrej Petras
Assignee: Jeff Mesnil
Attachments: mdb-tracer-jeager.png, mdb-tracer.zip
The onMessage method for the MessageDrivenBean is traced but the active span is null in the EJB interceptor.
{code:java}
if (tracer.activeSpan() == null) {
log.warn("No active span in the EJB interceptor!!!! Class:{} Method:{}", ic.getTarget().getClass(), ic.getMethod().getName());
}
{code}
Motivation: I would like to extend the information (tag,log) in the active span from the EJB interceptor.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11770) Do not generate example configurations in build module
by Alexey Loubyansky (Jira)
Alexey Loubyansky created WFLY-11770:
----------------------------------------
Summary: Do not generate example configurations in build module
Key: WFLY-11770
URL: https://issues.jboss.org/browse/WFLY-11770
Project: WildFly
Issue Type: Task
Components: Build System
Reporter: Alexey Loubyansky
Assignee: Alexey Loubyansky
Purely to reduce the build time. Provisioning of the example configurations on average doubles the time (e.g. provisioning build dist with example configs took on my laptop 16 sec and 7 sec w/o the example configs).
NOTE: the legacy build does include example configs, which means this will show up in diff comparing the two. If this is not desirable then this issue should be rejected.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (DROOLS-3692) java.lang.NullPointerException druing Condition Evaluation
by canyu canyu (Jira)
canyu canyu created DROOLS-3692:
-----------------------------------
Summary: java.lang.NullPointerException druing Condition Evaluation
Key: DROOLS-3692
URL: https://issues.jboss.org/browse/DROOLS-3692
Project: Drools
Issue Type: Sub-task
Affects Versions: 7.17.0.Final
Reporter: canyu canyu
Assignee: Mario Fusco
This happens when the number of same data attempts exceeds the drools.jittingThreshold.
Exception in thread "main" java.lang.RuntimeException: Error evaluating constraint 'valueOfDouble < bottomOfDouble * 0.3 || valueOfDouble > topOfDouble' in [Rule "1" in com/test/ec/drools/engine/mer/rules/medicalExaminationReportEvaluateRules.drl]
at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:274)
at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:222)
at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:139)
at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:378)
at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:323)
at org.drools.core.phreak.PropagationEntry$Insert.propagate(PropagationEntry.java:161)
at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:166)
at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:91)
at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1050)
at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1013)
at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1005)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1330)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1321)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1305)
at com.test.ec.drools.engine.mer.evaluator.MedicalExaminationReportEvaluator.evaluate(MedicalExaminationReportEvaluator.java:68)
at com.test.ec.drools.engine.mer.evaluator.MedicalExaminationReportEvaluator.main(MedicalExaminationReportEvaluator.java:174)
Caused by: java.lang.NullPointerException
at ConditionEvaluator08352c95cf9f4e5081f57208df9cb4e5.evaluate(Unknown Source)
at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:272)
... 17 more
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11678) ManagedExecutorService persists contextClassLoader reference to cause app classloader leaks
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11678?page=com.atlassian.jira.plugin... ]
James Perkins reassigned WFLY-11678:
------------------------------------
Assignee: Eduardo Martins (was: James Perkins)
Resolution: Done
> ManagedExecutorService persists contextClassLoader reference to cause app classloader leaks
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-11678
> URL: https://issues.jboss.org/browse/WFLY-11678
> Project: WildFly
> Issue Type: Bug
> Components: Concurrency Utilities
> Environment: -- EAP 7.1.4
> Reporter: Lei Yu
> Assignee: Eduardo Martins
> Priority: Critical
> Fix For: 16.0.0.CR1
>
>
> managed executor:
> {code}
> <managed-executor-services>
> <managed-executor-service name="default" jndi-name="java:jboss/ee/concurrency/executor/default" context-service="default" hung-task-threshold="60000" keepalive-time="5000"/>
> </managed-executor-services>
> {code}
> With each undeploy, the application classloader is leaked and not released because contextClassLoader references persisted on the executor threads:
> {code}
> Class Name | Ref. Objects | Shallow Heap | Ref. Shallow Heap | Retained Heap
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> org.jboss.as.ee.concurrent.service.ElytronManagedThreadFactory$ElytronManagedThread @ 0xc3677570 EE-ManagedExecutorService-default-Thread-13 Thread| 1 | 160 | 88 | 1,344
> '- contextClassLoader org.jboss.modules.ModuleClassLoader @ 0xc32b9d98 | 1 | 88 | 88 | 366,800
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> {code}
> Tracing with byteman, what's strange is that it sets the app classloader on setup:
> {code}
> Thread.setContextClassLoader: Thread[EE-ManagedExecutorService-default-Thread-16,5,ServerService ThreadGroup] ModuleClassLoader for Module "deployment.services-1.0.4-rc1.war" from Service Module Loader
> java.lang.Thread.setContextClassLoader(Thread.java:1477)
> org.wildfly.security.manager.WildFlySecurityManager.setCurrentContextClassLoaderPrivileged(WildFlySecurityManager.java:1272)
> org.jboss.as.ee.concurrent.handle.ClassLoaderContextHandleFactory$ClassLoaderSetupContextHandle.setup(ClassLoaderContextHandleFactory.java:83)
> org.jboss.as.ee.concurrent.ConcurrentContext$ChainedSetupContextHandle.setup(ConcurrentContext.java:166)
> org.jboss.as.ee.concurrent.DefaultContextSetupProviderImpl.setup(DefaultContextSetupProviderImpl.java:58)
> org.glassfish.enterprise.concurrent.internal.ManagedFutureTask.setupContext(ManagedFutureTask.java:121)
> org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor.beforeExecute(ManagedThreadPoolExecutor.java:109)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> java.lang.Thread.run(Thread.java:748)
> {code}
> And still sets that app classloader after task execution in the reset:
> {code}
> Thread.setContextClassLoader: Thread[EE-ManagedExecutorService-default-Thread-16,5,ServerService ThreadGroup] ModuleClassLoader for Module "deployment.services-1.0.4-rc1.war" from Service Module Loader
> java.lang.Thread.setContextClassLoader(Thread.java:1477)
> org.wildfly.security.manager.WildFlySecurityManager.setCurrentContextClassLoaderPrivileged(WildFlySecurityManager.java:1272)
> org.jboss.as.ee.concurrent.handle.ClassLoaderContextHandleFactory$ClassLoaderResetContextHandle.reset(ClassLoaderContextHandleFactory.java:113)
> org.jboss.as.ee.concurrent.ConcurrentContext$ChainedResetContextHandle.reset(ConcurrentContext.java:284)
> org.jboss.as.ee.concurrent.DefaultContextSetupProviderImpl.reset(DefaultContextSetupProviderImpl.java:63)
> org.glassfish.enterprise.concurrent.internal.ManagedFutureTask.resetContext(ManagedFutureTask.java:134)
> org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor.afterExecute(ManagedThreadPoolExecutor.java:90)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1157)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> java.lang.Thread.run(Thread.java:748)
> {code}
> So the thread is sitting in the pool with the app classloader. Is there some way we should be able to get the context loader cleared or unset from the app loader in the reset?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11710) Datasource metrics are not always exposed by the metrics subsystem
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11710?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-11710:
-----------------------------------------
Perhaps the MetricsRegistrationService collection of the root resource tree metrics could be moved out of start and called by MicroProfileMetricsSubsystemAdd in Stage.VERIFY. That's still an abuse of VERIFY but it doesn't involve adding a new service outside RUNTIME which I think the first approach to VERIFY did. We could say MetricsRegistrationService is "verifying" the runtime state by scanning for metrics. ;)
> Datasource metrics are not always exposed by the metrics subsystem
> ------------------------------------------------------------------
>
> Key: WFLY-11710
> URL: https://issues.jboss.org/browse/WFLY-11710
> Project: WildFly
> Issue Type: Bug
> Components: MP Metrics
> Affects Versions: 16.0.0.Beta1
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Critical
> Fix For: 16.0.0.CR1
>
>
> The metrics subsystem install a service at RUNTIME to register any metrics on the resources registered in WildFly management tree.
> However, the metrics for datasources are provided by the statistics=jdbc and statistics=pool children of the datasource resource which are installed at RUNTIME.
> Since there is no dependency between the metrics service and the service that installs the datasource statistics, it is possible that the metrics services is started before and while traverse the WildFly management tree before the statistics resources are added to it.
> This issue is intermittent and depend on the sequence of execution of unrelated services.
> To circumvent this issue, the metrics subsystem could install its service at VERIFY stage (instead of RUNTIME) and will then have the guarantee that any resources created at RUNTIME is present in WildFly management tree.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11664) EJB client 4 is unable to discover EJB after WildFly crash during previous call and reboot
by Flavia Rainone (Jira)
[ https://issues.jboss.org/browse/WFLY-11664?page=com.atlassian.jira.plugin... ]
Flavia Rainone closed WFLY-11664.
---------------------------------
Resolution: Out of Date
[~istraka] I just checked that the error is fixed in wildfly master. It cannot be reproduced with the code there. Automatically, this means that the bug will no longer be present in the next version of the server
> EJB client 4 is unable to discover EJB after WildFly crash during previous call and reboot
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-11664
> URL: https://issues.jboss.org/browse/WFLY-11664
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Remoting
> Affects Versions: 14.0.0.Final, 15.0.0.Final
> Reporter: Ivan Straka
> Assignee: Flavia Rainone
> Priority: Blocker
> Attachments: reproducer.zip
>
>
> Issue is not valid for 7.2.0.CD12 (upstream client: 12.0.0.Final) therefore we consider this as a blocker.
> Lets have two WildFly servers and same EJB on both. They have nothing to do with each other. And the client app that call beans on them.
> *Scenario*
> # Client invokes _hello_ method on the first server which crash during the call. Exception is consumed.
> # Client calls successfully _hello_ method on the second one.
> # Now, the first server is started again and then the client (same thread) try to call _hello_ on the first one. The call should be successful but the client is unable to discover bean.
> {code:java}Exception in thread "main" java.lang.RuntimeException: javax.ejb.NoSuchEJBException: EJBCLIENT000079: Unable to discover destination for request for EJB StatelessEJBLocator for "/server-1/HelloBean", view is interface ejb.HelloBeanRemote, affinity is None
> at client.Client.call(Client.java:41)
> at client.Client.main(Client.java:21)
> Caused by: javax.ejb.NoSuchEJBException: EJBCLIENT000079: Unable to discover destination for request for EJB StatelessEJBLocator for "/server-1/HelloBean", view is interface ejb.HelloBeanRemote, affinity is None
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:592)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:528)
> at org.jboss.ejb.protocol.remote.RemotingEJBClientInterceptor.handleInvocationResult(RemotingEJBClientInterceptor.java:56)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:594)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:528)
> at org.jboss.ejb.client.TransactionPostDiscoveryInterceptor.handleInvocationResult(TransactionPostDiscoveryInterceptor.java:133)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:594)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:528)
> at org.jboss.ejb.client.DiscoveryEJBClientInterceptor.handleInvocationResult(DiscoveryEJBClientInterceptor.java:115)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:594)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:528)
> at org.jboss.ejb.client.NamingEJBClientInterceptor.handleInvocationResult(NamingEJBClientInterceptor.java:79)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:594)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:528)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:172)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:594)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:528)
> at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:938)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:177)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:112)
> at com.sun.proxy.$Proxy0.hello(Unknown Source)
> at client.Client.call(Client.java:35)
> ... 1 more
> {code}
> I hit this issue with 15.0.0.Final, 14.0.0.Final but not with 12.0.0.Final.
> If client try to invoke _hello_ on the first server before it reboots (exception is consumed), there is no problem after.
> *Client side*
> {code:java}
> public static void main(String[] args)
> throws Exception {
> call("server-2", true);
> call("server-1", true);
> for (int i = 30; i > 0; i--) {
> System.out.println(i);
> Thread.sleep(1000);
> }
> call("server-1", false);
> }
> public static Properties getCtxProperties() {
> Properties props = new Properties();
> props.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
> return props;
> }
> public static void call(String container, boolean exceptedFailure) {
> try {
> InitialContext ctx = new InitialContext(getCtxProperties());
> String lookupName = "ejb:/" + container + "/HelloBean!ejb.HelloBeanRemote";
> HelloBeanRemote bean = (HelloBeanRemote) ctx.lookup(lookupName);
> System.out.println(bean.hello());
> } catch (Exception e) {
> if (exceptedFailure) {
> System.out.println("EXPECTED FAILURE");
> e.printStackTrace();
> } else {
> throw new RuntimeException(e);
> }
> }
> }
> {code}
> *Server side*
> {code:java}
> @Stateless
> @Remote(HelloBeanRemote.class)
> public class HelloBean {
> private static Logger log = Logger.getLogger(HelloBean.class);
> public String hello() throws RemoteException {
> log.info("hello called with message");
> return "Hello there";
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11769) The wrong SecurityIdentity may be used for EE concurrency threads that are reused
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11769?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-11769:
---------------------------------
Priority: Critical (was: Major)
> The wrong SecurityIdentity may be used for EE concurrency threads that are reused
> ---------------------------------------------------------------------------------
>
> Key: WFLY-11769
> URL: https://issues.jboss.org/browse/WFLY-11769
> Project: WildFly
> Issue Type: Bug
> Components: Concurrency Utilities, Security
> Reporter: James Perkins
> Assignee: Eduardo Martins
> Priority: Critical
>
> The {{ElytronManagedThread}} stores a {{SecurityIdentity}} to run the thread as. These threads do not necessarily terminate if the keep alive time has not expired. This could cause a shared thread to use the wrong security identity when executing. This should likely be handled in a {{SetupContextHandle}}, however we need to examine the performance impact of this.
> Using the {{SetupContextHandle}} would be the preferred method as it would need to execute after some of the other context handles so the correct TCCL would be seen for the {{SecurityDomain.getCurrent()}}.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months