[JBoss JIRA] (WFLY-12512) Intermittent failures in DynamicJNDIContextEJBInvocationTestCase
by Cheng Fang (Jira)
[ https://issues.jboss.org/browse/WFLY-12512?page=com.atlassian.jira.plugin... ]
Cheng Fang commented on WFLY-12512:
-----------------------------------
I was able to reproduce it with WildFly 18 snapshot (after commenting out the @Ignore line in {{DynamicJNDIContextEJBInvocationTestCase}}, and with the following command that mimics LInux+Elytron build:
mvn -U -Dinsecure.repositories=WARN -DallTests -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dipv6 -Delytron clean install
The important params seem to be {{-Dipv6 -Delytron}}
{code}
[ERROR] testServerToServerSFSBUsingEJB2xHomeView(org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase) Time elapsed: 0.093 s <<< ERROR!
javax.naming.NameNotFoundException: StatefulBeanA!org.jboss.as.test.multinode.remotecall.scoped.context.StatefulBeanA [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:184)
at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:239)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at javax.naming.InitialContext.doLookup(InitialContext.java:290)
at org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testServerToServerSFSBUsingEJB2xHomeView(DynamicJNDIContextEJBInvocationTestCase.java:187)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.jboss.arquillian.junit.Arquillian$8$1.invokeMethod(Arquillian.java:325)
at org.jboss.arquillian.junit.MethodInvoker$1.invoke(MethodInvoker.java:18)
at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:36)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:116)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:83)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:139)
at org.jboss.arquillian.junit.MethodInvoker.invoke(MethodInvoker.java:15)
at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:332)
at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:204)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:350)
at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:215)
at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:279)
at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:34)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:116)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:83)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:273)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:166)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:350)
at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:177)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:115)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:61)
at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:153)
at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:200)
at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:137)
at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:119)
at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:176)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1475)
at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
at org.jboss.as.jmx.AuthorizingMBeanServer.invoke(AuthorizingMBeanServer.java:258)
at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:71)
at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:66)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:313)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:270)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:66)
at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
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)
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)
... 156 more
{code}
> Intermittent failures in DynamicJNDIContextEJBInvocationTestCase
> ----------------------------------------------------------------
>
> Key: WFLY-12512
> URL: https://issues.jboss.org/browse/WFLY-12512
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 18.0.0.Beta1
> Reporter: Brian Stansberry
> Assignee: Cheng Fang
> Priority: Blocker
> Labels: blocker-WF18
> Fix For: 18.0.0.Final
>
>
> We're starting to see quite frequent intermittent failures of DynamicJNDIContextEJBInvocationTestCase.
> Looking at the history[1] it seems that this first started popping up with the EJB Client Interceptors PR.[2]
> [1] https://ci.wildfly.org/project.html?projectId=WF_PullRequest&buildTypeId=...
> [2] https://github.com/wildfly/wildfly/pull/12490
> I'm putting Blocker priority on this because it's a potential regression. But if it's not a regression, just a test that needs improvement, please lower the Priority right away, i.e. don't wait to fix the test.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFLY-12522) Memory Leak: RemoteConnectionHandler objects are created but not being freed when jboss-cli commands are executed
by super 6349 (Jira)
[ https://issues.jboss.org/browse/WFLY-12522?page=com.atlassian.jira.plugin... ]
super 6349 updated WFLY-12522:
------------------------------
Component/s: Remoting
> Memory Leak: RemoteConnectionHandler objects are created but not being freed when jboss-cli commands are executed
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-12522
> URL: https://issues.jboss.org/browse/WFLY-12522
> Project: WildFly
> Issue Type: Bug
> Components: CLI, Remoting
> Affects Versions: 16.0.0.Final, 17.0.0.Final, 17.0.1.Final
> Reporter: super 6349
> Assignee: Jean Francois Denise
> Priority: Major
>
> When the user executes jboss-cli commands on a fresh installation of wildfly, RemoteConnectionHandler objects are created but never released.
> We identified this problem when we configured a readiness probe on openshift using jboss-cli (repeating every 15 seconds) and the memory started to increase along the days. The application was in development and nobody was accessing it, but the memory increased nonetheless.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFLY-12522) Memory Leak: RemoteConnectionHandler objects are created but not being freed when jboss-cli commands are executed
by super 6349 (Jira)
super 6349 created WFLY-12522:
---------------------------------
Summary: Memory Leak: RemoteConnectionHandler objects are created but not being freed when jboss-cli commands are executed
Key: WFLY-12522
URL: https://issues.jboss.org/browse/WFLY-12522
Project: WildFly
Issue Type: Bug
Components: CLI
Affects Versions: 17.0.1.Final, 17.0.0.Final, 16.0.0.Final
Reporter: super 6349
Assignee: Jean Francois Denise
When the user executes jboss-cli commands on a fresh installation of wildfly, RemoteConnectionHandler objects are created but never released.
We identified this problem when we configured a readiness probe on openshift using jboss-cli (repeating every 15 seconds) and the memory started to increase along the days. The application was in development and nobody was accessing it, but the memory increased nonetheless.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFWIP-186) PVC access mode is hardcoded to ReadWriteOnce
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFWIP-186?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFWIP-186:
-----------------------------------
I think this is not an issue.
It is correct that the PVC for each pod is mounted as ReadWriteOnce since only one pod should access it (PV are not shared between Pods).
I followed Prometheus convention to reuse the PersistentVolumeClaim to configure the PVC but only a subset of the spec is actually used:
* the resources (for requests and limits)
* the selector
I can update the documentation to clarify which part of the PersistentVolumeClaim spec is actually taken into account.
Re `oc edit pvc simple-jaxrs-eap72-volume-simple-jaxrs-eap72-0`, the spec (the desired feature) correctly states that the accessModes is `ReadWriteOnce`, while the status (the actual feature) supports both `ReadWriteOnce` and `ReadWriteMany`
> PVC access mode is hardcoded to ReadWriteOnce
> ---------------------------------------------
>
> Key: WFWIP-186
> URL: https://issues.jboss.org/browse/WFWIP-186
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> Setting different access mode (ReadWriteMany, ReadOnlyMany) is ignored
> [1] https://github.com/wildfly/wildfly-operator/blob/master/pkg/controller/wi...
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (DROOLS-4503) "Error" popup report java literal for suggested number
by Yeser Amer (Jira)
[ https://issues.jboss.org/browse/DROOLS-4503?page=com.atlassian.jira.plugi... ]
Yeser Amer updated DROOLS-4503:
-------------------------------
Labels: ScenarioSimulation (was: )
> "Error" popup report java literal for suggested number
> ------------------------------------------------------
>
> Key: DROOLS-4503
> URL: https://issues.jboss.org/browse/DROOLS-4503
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.26.0.Final
> Reporter: Gabriele Cardosi
> Assignee: Yeser Amer
> Priority: Major
> Labels: ScenarioSimulation
> Attachments: ErrorPopup.png, FollowError.png, InsertedValue.png
>
>
> When the expected value for a field is a java long, the error popup reports
> "The expected value is '2' but the actual one is '3L'."
> !ErrorPopup.png|thumbnail!
> That means the java literal is used for the suggested (correct) value, while the inserted value as-is is shown as the one to correct. _Of course it is possible that this apply to all types whose java literal representation is different then "absolute" value._
> This is a little bit inconsistent and confusing, especially for someone not knowing java.
> The worst consequence is that when user click "Apply", that literal is put inside the cell,
> !InsertedValue.png|thumbnail!
> and when sent to server it raise error (because server is expecting a number, not a string)
> !FollowError.png|thumbnail!
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (DROOLS-4503) "Error" popup report java literal for suggested number
by Yeser Amer (Jira)
[ https://issues.jboss.org/browse/DROOLS-4503?page=com.atlassian.jira.plugi... ]
Yeser Amer updated DROOLS-4503:
-------------------------------
Affects Version/s: 7.26.0.Final
> "Error" popup report java literal for suggested number
> ------------------------------------------------------
>
> Key: DROOLS-4503
> URL: https://issues.jboss.org/browse/DROOLS-4503
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.26.0.Final
> Reporter: Gabriele Cardosi
> Assignee: Yeser Amer
> Priority: Major
> Labels: ScenarioSimulation
> Attachments: ErrorPopup.png, FollowError.png, InsertedValue.png
>
>
> When the expected value for a field is a java long, the error popup reports
> "The expected value is '2' but the actual one is '3L'."
> !ErrorPopup.png|thumbnail!
> That means the java literal is used for the suggested (correct) value, while the inserted value as-is is shown as the one to correct. _Of course it is possible that this apply to all types whose java literal representation is different then "absolute" value._
> This is a little bit inconsistent and confusing, especially for someone not knowing java.
> The worst consequence is that when user click "Apply", that literal is put inside the cell,
> !InsertedValue.png|thumbnail!
> and when sent to server it raise error (because server is expecting a number, not a string)
> !FollowError.png|thumbnail!
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFWIP-185) PVC not deleted by deleting WildFlyServer CR
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFWIP-185?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFWIP-185:
-----------------------------------
It seems that it is a Kubernetes feature that PVC are not deleted when the StatefulSetStatus is delete: https://github.com/kubernetes/kubernetes/issues/55045
Note that there is a PR to make sure that PVC are properly owned by the statefulset at https://github.com/kubernetes/kubernetes/pull/75163 that is under discussion.
> PVC not deleted by deleting WildFlyServer CR
> --------------------------------------------
>
> Key: WFWIP-185
> URL: https://issues.jboss.org/browse/WFWIP-185
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> When I delete WildFlyServer CR PVC created by this CR is not deleted as StatefullSet and Pods are .
> I see Statefull Set and Pod has ownerReferences attribute referencing to parent.
> ownerReferences
> List of objects depended by this object. If ALL objects in the list have been deleted, this object will be garbage collected. If this object is managed by a controller, then an entry in this list will point to this controller, with the controller field set to true. There cannot be more than one managing controller.
> I dont see such attribute specified in PVC
> {code}
> # Please edit the object below. Lines beginning with a '#' will be ignored,
> # and an empty file will abort the edit. If an error occurs while saving this file will be
> # reopened with the relevant failures.
> #
> apiVersion: v1
> kind: PersistentVolumeClaim
> metadata:
> annotations:
> pv.kubernetes.io/bind-completed: "yes"
> pv.kubernetes.io/bound-by-controller: "yes"
> creationTimestamp: 2019-08-30T13:12:27Z
> finalizers:
> - kubernetes.io/pvc-protection
> labels:
> app.kubernetes.io/managed-by: wildfly-operator
> app.kubernetes.io/name: simple-jaxrs-eap72
> app.openshift.io/runtime: wildfly
> name: simple-jaxrs-eap72-volume-simple-jaxrs-eap72-0
> namespace: mchoma
> resourceVersion: "3633284"
> selfLink: /api/v1/namespaces/mchoma/persistentvolumeclaims/simple-jaxrs-eap72-volume-simple-jaxrs-eap72-0
> uid: d0aac389-cb27-11e9-b93c-fa163e9a0fb6
> spec:
> accessModes:
> - ReadWriteOnce
> resources:
> requests:
> storage: 1Mi
> volumeName: vol57
> status:
> accessModes:
> - ReadWriteMany
> - ReadWriteOnce
> capacity:
> storage: 1Gi
> phase: Bound
> {code}
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months