[JBoss JIRA] (WFCORE-3059) suggest-capabilities returns suffix when the capability contains a dot
by Claudio Miranda (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3059?page=com.atlassian.jira.plugi... ]
Claudio Miranda updated WFCORE-3059:
------------------------------------
Component/s: Security
> suggest-capabilities returns suffix when the capability contains a dot
> ----------------------------------------------------------------------
>
> Key: WFCORE-3059
> URL: https://issues.jboss.org/browse/WFCORE-3059
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Claudio Miranda
>
> Given the following operation to add credential-store.
> {code}
> /profile=full/subsystem=elytron/credential-store=store.foo:add(relative-to=jboss.server.data.dir, credential-reference={clear-text=pass123},create)
> /profile=full/subsystem=elytron/credential-store=store2:add(relative-to=jboss.server.data.dir, credential-reference={clear-text=pass123},create)
> {code}
> There is a problem related to the naming used in "store.foo", the suggest-capabilities operation will return only the suffix "foo" instead of the resource name "store.foo"
> {code}
> /host=master/core-service=capability-registry:suggest-capabilities(name=org.wildfly.security.credential-store,dependent-address=[("profile" => "full"),("subsystem" => "elytron"),("credential-store" => "*")])
> {
> "outcome" => "success",
> "result" => [
> "store2",
> "foo"
> ]
> }
> {code}
> This presents a problem for capability-reference, as the auto complete on CLI (using tab) and Web Console returns "foo" and "store2" as value.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFCORE-3059) suggest-capabilities returns suffix when the capability contains a dot
by Claudio Miranda (JIRA)
Claudio Miranda created WFCORE-3059:
---------------------------------------
Summary: suggest-capabilities returns suffix when the capability contains a dot
Key: WFCORE-3059
URL: https://issues.jboss.org/browse/WFCORE-3059
Project: WildFly Core
Issue Type: Bug
Reporter: Claudio Miranda
Given the following operation to add credential-store.
{code}
/profile=full/subsystem=elytron/credential-store=store.foo:add(relative-to=jboss.server.data.dir, credential-reference={clear-text=pass123},create)
/profile=full/subsystem=elytron/credential-store=store2:add(relative-to=jboss.server.data.dir, credential-reference={clear-text=pass123},create)
{code}
There is a problem related to the naming used in "store.foo", the suggest-capabilities operation will return only the suffix "foo" instead of the resource name "store.foo"
{code}
/host=master/core-service=capability-registry:suggest-capabilities(name=org.wildfly.security.credential-store,dependent-address=[("profile" => "full"),("subsystem" => "elytron"),("credential-store" => "*")])
{
"outcome" => "success",
"result" => [
"store2",
"foo"
]
}
{code}
This presents a problem for capability-reference, as the auto complete on CLI (using tab) and Web Console returns "foo" and "store2" as value.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (DROOLS-1652) Add an entry point on the kie-server to deploy a DMN files as a service
by Maciej Swiderski (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1652?page=com.atlassian.jira.plugi... ]
Maciej Swiderski commented on DROOLS-1652:
------------------------------------------
I don't think we should make this for jBPM as by nature it is stateful so once you create such resource and bounce the server it's gone while the data in db remains - kind of orphans.
That in general applies to stateless/in memory stuff too, how would you deal with server restarts? Or is this intended for quick checks of resources?
My vote is to include it in DMN extension or Drools if you would like to support other rule related resource types.
> Add an entry point on the kie-server to deploy a DMN files as a service
> -----------------------------------------------------------------------
>
> Key: DROOLS-1652
> URL: https://issues.jboss.org/browse/DROOLS-1652
> Project: Drools
> Issue Type: Feature Request
> Components: dmn engine, kie server
> Affects Versions: 7.1.0.Beta3
> Reporter: Edson Tirelli
> Assignee: Duncan Doyle
>
> Add an end point on the kie-server to deploy a DMN xml file directly as a service without the need for a kjar.
> In other words, the end point would accept a POST with a DMN xml file as a payload, it would internally build a kjar in memory and deploy it as a kie-container.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-9073) Thread Leak in jboss-client on JMX remoting authentication failure
by Piotr Krokowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-9073?page=com.atlassian.jira.plugin.... ]
Piotr Krokowski edited comment on WFLY-9073 at 7/11/17 1:52 PM:
----------------------------------------------------------------
Forgive me, if my JVM knowledge is limited, but I'm not configuring any ThreadPoolExecutor, I'm not supplying any JVM parameters.
In this plain example, I'm running java with it's defaults, and observe, that the number of connections spikes, beyond any reasonable limit.
AFAIK the JMXConnectorFactory doesn't expose any API to inject any executor.
I'm also not aware of any global switches for JVM that would configure such limits (correct me if I'm wrong, I might learn something).
Please investigate the code, as I've highlighted in the description. The objects that are initialized during internalConnect are never cleaned up.
EDIT: In other words, if there's any executor, it's internally encapsulated by the jboss-client implementation. I'm indirectly using it though JMX API.
was (Author: piotr.krokowski.sabre):
Forgive me, if my JVM knowledge is limited, but I'm not configuring any ThreadPoolExecutor, I'm not supplying any JVM parameters.
In this plain example, I'm running java with it's defaults, and observe, that the number of connections spikes, beyond any reasonable limit.
AFAIK the JMXConnectorFactory doesn't expose any API to inject any executor.
I'm also not aware of any global switches for JVM that would configure such limits (correct me if I'm wrong, I might learn something).
Please investigate the code, as I've highlighted in the description. The objects that are initialized during internalConnect are never cleaned up.
> Thread Leak in jboss-client on JMX remoting authentication failure
> ------------------------------------------------------------------
>
> Key: WFLY-9073
> URL: https://issues.jboss.org/browse/WFLY-9073
> Project: WildFly
> Issue Type: Bug
> Components: Application Client, JMX
> Affects Versions: 10.1.0.Final
> Reporter: Piotr Krokowski
> Assignee: Stuart Douglas
> Attachments: JbossClientThreadLeakDemo.java
>
>
> I've observed, that authentication failure, while connecting with jboss-client implementation of JMX remoting (remote+http) causes a thread leak.
> Please find the attached code snippet to reproduce the faulty behavior.
> The attached code produces following output in my case :
> Thread count before starting: 2
> Active threads AFTER start: 2
> Connection failed.
> Active threads AFTER after success: 7
> Connection failed.
> Active threads AFTER after failure: 12
> Possible cause.
> After an initial analisys I've observed that RemotingConnector.internalConnect throws an Exception, while having state set to UNUSED, while I'd actually expect it being set to OPEN, as connection and endpoint fields are already initialized.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-9073) Thread Leak in jboss-client on JMX remoting authentication failure
by Piotr Krokowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-9073?page=com.atlassian.jira.plugin.... ]
Piotr Krokowski commented on WFLY-9073:
---------------------------------------
Forgive me, if my JVM knowledge is limited, but I'm not configuring any ThreadPoolExecutor, I'm not supplying any JVM parameters.
In this plain example, I'm running java with it's defaults, and observe, that the number of connections spikes, beyond any reasonable limit.
AFAIK the JMXConnectorFactory doesn't expose any API to inject any executor.
I'm also not aware of any global switches for JVM that would configure such limits (correct me if I'm wrong, I might learn something).
Please investigate the code, as I've highlighted in the description. The objects that are initialized during internalConnect are never cleaned up.
> Thread Leak in jboss-client on JMX remoting authentication failure
> ------------------------------------------------------------------
>
> Key: WFLY-9073
> URL: https://issues.jboss.org/browse/WFLY-9073
> Project: WildFly
> Issue Type: Bug
> Components: Application Client, JMX
> Affects Versions: 10.1.0.Final
> Reporter: Piotr Krokowski
> Assignee: Stuart Douglas
> Attachments: JbossClientThreadLeakDemo.java
>
>
> I've observed, that authentication failure, while connecting with jboss-client implementation of JMX remoting (remote+http) causes a thread leak.
> Please find the attached code snippet to reproduce the faulty behavior.
> The attached code produces following output in my case :
> Thread count before starting: 2
> Active threads AFTER start: 2
> Connection failed.
> Active threads AFTER after success: 7
> Connection failed.
> Active threads AFTER after failure: 12
> Possible cause.
> After an initial analisys I've observed that RemotingConnector.internalConnect throws an Exception, while having state set to UNUSED, while I'd actually expect it being set to OPEN, as connection and endpoint fields are already initialized.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-9073) Thread Leak in jboss-client on JMX remoting authentication failure
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-9073?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-9073:
-----------------------------------
I ask because (for example) ThreadPoolExecutor will create a new thread on every task submission up to the core size. This means that if your pool size is (for example) 100, and your authentication attempt executes 10 tasks, it will cause 10 threads to be created; another similar attempt will create another 10 threads, etc. So the observation of an increasing number of threads can be explained by defined behavior and is not actually a leak. The state of the existent threads and the observation of a hang are all circumstantial bits of information.
> Thread Leak in jboss-client on JMX remoting authentication failure
> ------------------------------------------------------------------
>
> Key: WFLY-9073
> URL: https://issues.jboss.org/browse/WFLY-9073
> Project: WildFly
> Issue Type: Bug
> Components: Application Client, JMX
> Affects Versions: 10.1.0.Final
> Reporter: Piotr Krokowski
> Assignee: Stuart Douglas
> Attachments: JbossClientThreadLeakDemo.java
>
>
> I've observed, that authentication failure, while connecting with jboss-client implementation of JMX remoting (remote+http) causes a thread leak.
> Please find the attached code snippet to reproduce the faulty behavior.
> The attached code produces following output in my case :
> Thread count before starting: 2
> Active threads AFTER start: 2
> Connection failed.
> Active threads AFTER after success: 7
> Connection failed.
> Active threads AFTER after failure: 12
> Possible cause.
> After an initial analisys I've observed that RemotingConnector.internalConnect throws an Exception, while having state set to UNUSED, while I'd actually expect it being set to OPEN, as connection and endpoint fields are already initialized.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-9061) LazyTransactionEnlistmentUnitTestCase#testRawSQL fails with security manager
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/WFLY-9061?page=com.atlassian.jira.plugin.... ]
Amos Feng reassigned WFLY-9061:
-------------------------------
Assignee: Amos Feng
> LazyTransactionEnlistmentUnitTestCase#testRawSQL fails with security manager
> ----------------------------------------------------------------------------
>
> Key: WFLY-9061
> URL: https://issues.jboss.org/browse/WFLY-9061
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Test Suite, Transactions
> Affects Versions: 11.0.0.Beta1
> Reporter: Ondrej Kotek
> Assignee: Amos Feng
> Priority: Blocker
> Labels: security-manager
>
> {{LazyTransactionEnlistmentUnitTestCase#testRawSQL}} fails with security manager:
> {noformat}LazyTransactionEnlistmentUnitTestCase.testRawSQL:82 expected:<875000.0> but was:<625000.0>{noformat}
> It is not obvious why does it fail. In case the same conditions can occur in a real application, it may lead to unexpected and undesirable behaviour. Setting priority to Blocker, proper investigation is necessary.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-9074) NPE o.j.a.ejb3.component.stateful.StatefulComponentSessionIdGeneratingInterceptor.processInvocation()
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-9074?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-9074:
-----------------------------------
Right this looks amazingly similar to WFLY-6663 but is actually a different issue - possibly very different. [~pferraro] could this be related to the recent clustering-related startup changes?
> NPE o.j.a.ejb3.component.stateful.StatefulComponentSessionIdGeneratingInterceptor.processInvocation()
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-9074
> URL: https://issues.jboss.org/browse/WFLY-9074
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Reporter: Darryl Miles
>
> https://issues.jboss.org/browse/WFLY-6663 (see fix for this other bug, maybe the 1 line wait method is needed somewhere else too?)
> Much more intermittent matter (I guess the time window is smaller).
> 16:14:04,428 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 19) MSC000001: Failed to start service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> 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:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163)
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:138)
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> ... 6 more
> Caused by: javax.ejb.EJBException: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:83)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:91)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:106)
> at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.singleton.StartupCountDownInterceptor.processInvocation(StartupCountDownInterceptor.java:25)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
> ... 11 more
> Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:319)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:97)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> ... 28 more
> Caused by: javax.naming.NameNotFoundException: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb [Root exception is java.lang.IllegalStateException: WFLYEE0046: Failed to instantiate component view]
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:153)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
> ... 45 more
> Caused by: java.lang.IllegalStateException: WFLYEE0046: Failed to instantiate component view
> at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:58)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143)
> ... 50 more
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ejb3.component.stateful.StatefulComponentSessionIdGeneratingInterceptor.processInvocation(StatefulComponentSessionIdGeneratingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$DefaultViewInstanceFactory.createViewInstance(ViewService.java:305)
> at org.jboss.as.ee.component.ViewService$View.createInstance(ViewService.java:184)
> at org.jboss.as.ee.component.ViewService$View.createInstance(ViewService.java:174)
> at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:56)
> ... 51 more
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-9073) Thread Leak in jboss-client on JMX remoting authentication failure
by Piotr Krokowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-9073?page=com.atlassian.jira.plugin.... ]
Piotr Krokowski commented on WFLY-9073:
---------------------------------------
Every connection attempt adds a few another threads, that are never stopped.
After some time the JVM hangs. Thread dump shows enormous number of threads in RUNNING and (if I remember correctly) WAITING state.
That I'd consider a leak.
> Thread Leak in jboss-client on JMX remoting authentication failure
> ------------------------------------------------------------------
>
> Key: WFLY-9073
> URL: https://issues.jboss.org/browse/WFLY-9073
> Project: WildFly
> Issue Type: Bug
> Components: Application Client, JMX
> Affects Versions: 10.1.0.Final
> Reporter: Piotr Krokowski
> Assignee: Stuart Douglas
> Attachments: JbossClientThreadLeakDemo.java
>
>
> I've observed, that authentication failure, while connecting with jboss-client implementation of JMX remoting (remote+http) causes a thread leak.
> Please find the attached code snippet to reproduce the faulty behavior.
> The attached code produces following output in my case :
> Thread count before starting: 2
> Active threads AFTER start: 2
> Connection failed.
> Active threads AFTER after success: 7
> Connection failed.
> Active threads AFTER after failure: 12
> Possible cause.
> After an initial analisys I've observed that RemotingConnector.internalConnect throws an Exception, while having state set to UNUSED, while I'd actually expect it being set to OPEN, as connection and endpoint fields are already initialized.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months