[JBoss JIRA] (WFLY-5197) Intermittent javax.ejb.EJBException: Do not call non-public methods on EJB's
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5197?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-5197:
------------------------------------
Assignee: Stuart Douglas
> Intermittent javax.ejb.EJBException: Do not call non-public methods on EJB's
> ----------------------------------------------------------------------------
>
> Key: WFLY-5197
> URL: https://issues.jboss.org/browse/WFLY-5197
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EJB
> Affects Versions: 10.0.0.Beta2
> Reporter: Tomas Remes
> Assignee: Stuart Douglas
>
> It's intermittently failing in CDI TCK in org.jboss.cdi.tck.interceptors.tests.contract.lifecycleCallback.LifecycleCallbackInterceptorTest. There is:
> {code}
> @Stateful
> @Interceptors(CatInterceptor.class)
> public class Cat extends Animal {
> ...
> @Override
> public void foo() {
> }
> ...
> }
> {code}
> and:
> {code}
> public abstract class Animal {
>
> ...
> void foo() {
> }
> ....
> }
> {code}
> There is check in {{org.jboss.as.ejb3.component.session.SessionBeanComponentDescription#addNoInterfaceView}} whether method is public. This check is sometimes called for {{Animal.foo()}} and sometimes for {{Cat.foo()}}. I think only {{Cat.foo()}} should be checked.
> Stacktrace is:
> {noformat}
> javax.ejb.EJBException: WFLYEJB0224: Not a business method void org.jboss.cdi.tck.interceptors.tests.contract.lifecycleCallback.Animal.foo(). Do not call non-public methods on EJB's
> at org.jboss.as.ejb3.component.session.NotBusinessMethodInterceptor.processInvocation(NotBusinessMethodInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> at org.jboss.cdi.tck.interceptors.tests.contract.lifecycleCallback.Cat$$$view2.foo(Unknown Source)
> 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:483)
> at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:436)
> at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127)
> at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> at org.jboss.cdi.tck.interceptors.tests.contract.lifecycleCallback.Cat$Proxy$_$$_Weld$EnterpriseProxy$.foo(Unknown Source)
> at org.jboss.cdi.tck.interceptors.tests.contract.lifecycleCallback.LifecycleCallbackInterceptorTest.createAndDestroyInstance(LifecycleCallbackInterceptorTest.java:87)
> at org.jboss.cdi.tck.interceptors.tests.contract.lifecycleCallback.LifecycleCallbackInterceptorTest.testLifecycleCallbackInterceptorTransactionContext(LifecycleCallbackInterceptorTest.java:137)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-5197) Intermittent javax.ejb.EJBException: Do not call non-public methods on EJB's
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5197?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-5197:
--------------------------------------
Yes, I will fix
> Intermittent javax.ejb.EJBException: Do not call non-public methods on EJB's
> ----------------------------------------------------------------------------
>
> Key: WFLY-5197
> URL: https://issues.jboss.org/browse/WFLY-5197
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EJB
> Affects Versions: 10.0.0.Beta2
> Reporter: Tomas Remes
> Assignee: Stuart Douglas
>
> It's intermittently failing in CDI TCK in org.jboss.cdi.tck.interceptors.tests.contract.lifecycleCallback.LifecycleCallbackInterceptorTest. There is:
> {code}
> @Stateful
> @Interceptors(CatInterceptor.class)
> public class Cat extends Animal {
> ...
> @Override
> public void foo() {
> }
> ...
> }
> {code}
> and:
> {code}
> public abstract class Animal {
>
> ...
> void foo() {
> }
> ....
> }
> {code}
> There is check in {{org.jboss.as.ejb3.component.session.SessionBeanComponentDescription#addNoInterfaceView}} whether method is public. This check is sometimes called for {{Animal.foo()}} and sometimes for {{Cat.foo()}}. I think only {{Cat.foo()}} should be checked.
> Stacktrace is:
> {noformat}
> javax.ejb.EJBException: WFLYEJB0224: Not a business method void org.jboss.cdi.tck.interceptors.tests.contract.lifecycleCallback.Animal.foo(). Do not call non-public methods on EJB's
> at org.jboss.as.ejb3.component.session.NotBusinessMethodInterceptor.processInvocation(NotBusinessMethodInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> at org.jboss.cdi.tck.interceptors.tests.contract.lifecycleCallback.Cat$$$view2.foo(Unknown Source)
> 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:483)
> at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:436)
> at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127)
> at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> at org.jboss.cdi.tck.interceptors.tests.contract.lifecycleCallback.Cat$Proxy$_$$_Weld$EnterpriseProxy$.foo(Unknown Source)
> at org.jboss.cdi.tck.interceptors.tests.contract.lifecycleCallback.LifecycleCallbackInterceptorTest.createAndDestroyInstance(LifecycleCallbackInterceptorTest.java:87)
> at org.jboss.cdi.tck.interceptors.tests.contract.lifecycleCallback.LifecycleCallbackInterceptorTest.testLifecycleCallbackInterceptorTransactionContext(LifecycleCallbackInterceptorTest.java:137)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-5184) Read-attribute on an EJB timer fails if there are no more timeouts
by Jan Martiska (JIRA)
[ https://issues.jboss.org/browse/WFLY-5184?page=com.atlassian.jira.plugin.... ]
Jan Martiska updated WFLY-5184:
-------------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/7978 (was: https://issues.jboss.org/browse/WFLY-5184)
> Read-attribute on an EJB timer fails if there are no more timeouts
> ------------------------------------------------------------------
>
> Key: WFLY-5184
> URL: https://issues.jboss.org/browse/WFLY-5184
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Beta2
> Reporter: Jan Martiska
> Assignee: Jan Martiska
>
> When a read-attribute operation is invoked on an EJB timer that has no timeouts remaining, the operation fails without returning any useful information to the client:
> {noformat}
> {
> "outcome" : "failed",
> "rolled-back" : true
> }
> {noformat}
> It is because a NoMoreTimeoutException is thrown from the TimerServiceImpl and this exception is not handled by the read-attribute handler. This occurs in the server log:
> {noformat}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("deployment" => "ejb-mgmt-timers.jar"),
> ("subsystem" => "ejb3"),
> ("stateless-session-bean" => "TimerBean"),
> ("service" => "timer-service"),
> ("timer" => "9a93b559-3526-4b72-95e7-760c5bc50484")
> ]): javax.ejb.NoMoreTimeoutsException: WFLYEJB0328: No more timeouts for timer [id=9a93b559-3526-4b72-95e7-760c5bc50484 timedObjectId=ejb-mgmt-timers.ejb-mgmt-timers.TimerBean auto-timer?:false persistent?:true timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@72e447ae initialExpiration=Mon Aug 24 13:38:37 CEST 2015 intervalDuration(in milli sec)=0 nextExpiration=null timerState=IN_TIMEOUT info=PersistentIntervalTimerCLITestCase]
> at org.jboss.as.ejb3.timerservice.TimerImpl.getNextTimeout(TimerImpl.java:256)
> at org.jboss.as.ejb3.subsystem.deployment.TimerResourceDefinition$6.readAttribute(TimerResourceDefinition.java:240)
> at org.jboss.as.ejb3.subsystem.deployment.TimerResourceDefinition$AbstractReadAttributeHandler.executeRuntime(TimerResourceDefinition.java:376)
> at org.jboss.as.ejb3.subsystem.deployment.TimerResourceDefinition$AbstractTimerHandler$1.execute(TimerResourceDefinition.java:340)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:846)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:637)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:362)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1272)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:394)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:225)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:207)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:129)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:151)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:147)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:147)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:298)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
> 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}
> I think the read-attribute handler should rather catch this exception, log it, and leave the next-timeout and time-remaining attributes undefined in this case.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-5195) Persistent timers sometimes remain IN_TIMEOUT in database and don't ever activate again
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5195?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-5195:
--------------------------------------
I have fixed this by simply modifying the timer state back to active.
There are still some issues with clustered timers though, that basically relate to failed task detection (e.g. if a node in the cluster goes away with a task in IN_TIMEOUT, then other cluster nodes will not pick up the task). This requires quite a bit of feature development that I think is outside the scope of EAP7.0. To workaround this we should recommend that nodes are always shut down using graceful shutdown, as this will prevent this occurring.
> Persistent timers sometimes remain IN_TIMEOUT in database and don't ever activate again
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-5195
> URL: https://issues.jboss.org/browse/WFLY-5195
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Beta2
> Reporter: Jan Martiska
> Assignee: Stuart Douglas
> Attachments: in-timeout-reproducer.zip
>
>
> The scenario:
> A persistent timer goes off right before its application gets undeployed
> {noformat}
> [0m[32m08:43:38,086 DEBUG [org.jboss.as.ejb3] (EJB default - 1) Timer task invoked at: Tue Aug 25 08:43:38 CEST 2015 for timer [id=d563c5b3-c98c-44c9-87f6-04a492280a67 timedObjectId=testTimerServiceSerialization.a.TimerServiceSerializationBean auto-timer?:false persistent?:true timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@43ca0624 initialExpiration=Tue Aug 25 08:43:35 CEST 2015 intervalDuration(in milli sec)=100 nextExpiration=Tue Aug 25 08:43:38 CEST 2015 timerState=ACTIVE info=org.jboss.as.test.integration.ejb.timerservice.serialization.InfoA@1ce85ecb]
> {noformat}
> The timer changes its state to IN_TIMEOUT and persists this into the database.
> It fails to invoke the bean method, because the application is no longer available
> {noformat}
> [0m[31m08:43:38,515 ERROR [org.jboss.as.ejb3] (EJB default - 1) WFLYEJB0020: Error invoking timeout for timer: [id=d563c5b3-c98c-44c9-87f6-04a492280a67 timedObjectId=testTimerServiceSerialization.a.TimerServiceSerializationBean auto-timer?:false persistent?:true timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@43ca0624 initialExpiration=Tue Aug 25 08:43:35 CEST 2015 intervalDuration(in milli sec)=100 nextExpiration=Tue Aug 25 08:43:38 CEST 2015 timerState=IN_TIMEOUT info=org.jboss.as.test.integration.ejb.timerservice.serialization.InfoA@1ce85ecb]: java.lang.IllegalStateException
> at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.getInvoker(TimerServiceImpl.java:564)
> at org.jboss.as.ejb3.timerservice.TimerTask.invokeBeanMethod(TimerTask.java:188)
> at org.jboss.as.ejb3.timerservice.TimerTask.callTimeout(TimerTask.java:184)
> at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:157)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1224)
> at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:497)
> 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}
> It considers retrying, but then it doesn't retry, because the state is IN_TIMEOUT
> {noformat}
> 08:43:38,515 INFO [org.jboss.as.ejb3] (EJB default - 1) WFLYEJB0021: Timer: [id=d563c5b3-c98c-44c9-87f6-04a492280a67 timedObjectId=testTimerServiceSerialization.a.TimerServiceSerializationBean auto-timer?:false persistent?:true timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@43ca0624 initialExpiration=Tue Aug 25 08:43:35 CEST 2015 intervalDuration(in milli sec)=100 nextExpiration=Tue Aug 25 08:43:38 CEST 2015 timerState=IN_TIMEOUT info=org.jboss.as.test.integration.ejb.timerservice.serialization.InfoA@1ce85ecb] will be retried
> 08:43:38,515 INFO [org.jboss.as.ejb3] (EJB default - 1) WFLYEJB0024: Timer is not active, skipping retry of timer: [id=d563c5b3-c98c-44c9-87f6-04a492280a67 timedObjectId=testTimerServiceSerialization.a.TimerServiceSerializationBean auto-timer?:false persistent?:true timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@43ca0624 initialExpiration=Tue Aug 25 08:43:35 CEST 2015 intervalDuration(in milli sec)=100 nextExpiration=Tue Aug 25 08:43:38 CEST 2015 timerState=IN_TIMEOUT info=org.jboss.as.test.integration.ejb.timerservice.serialization.InfoA@1ce85ecb]
> {noformat}
> It gives up and tries to persist the state back to ACTIVE, but it fails, because the DatabaseTimerPersistence service is no longer available
> {noformat}
> 08:43:38,516 WARN [org.jboss.as.ejb3] (EJB default - 1) WFLYEJB0016: Timer persistence is not enabled, persistent timers will not survive JVM restarts
> {noformat}
> So the state remains IN_TIMEOUT in the database. When the application is redeployed, it is initialized with this state and it never goes off again.
> This happens with a JDBC storage in a database that is slow enough so that the update of state to IN_TIMEOUT proceeds correctly, but the actual bean method invocation fails already.
> Attaching a reproducer which simulates a slow database using Byteman, so it can be run even with the ExampleDS.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFCORE-915) Allow concurrent registration of slave host controllers
by James Livingston (JIRA)
[ https://issues.jboss.org/browse/WFCORE-915?page=com.atlassian.jira.plugin... ]
James Livingston commented on WFCORE-915:
-----------------------------------------
Another possibility may also be to change it to a ReentrantReadWriteLock rather than a ReentrantLock, and make the controller registration take a read lock on it (other uses taking the write lock). If there are any other use cases for needing a consistent config but not making changes themselves (I have no idea if there are), it would allow them to be done concurrently too.
The other changes you suggest would probably still be needed or useful with that.
> Allow concurrent registration of slave host controllers
> -------------------------------------------------------
>
> Key: WFCORE-915
> URL: https://issues.jboss.org/browse/WFCORE-915
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
>
> Registration of slave host controllers must be done with the exclusive ModelController lock held, in order to ensure that the registering HC sees a consistent config throughout the entire process. The drawback to this is registrations must therefore be done in series, which is inefficient in a large domain.
> We need to evaluate how this can be done in parallel, without losing the correctness semantics. For example, have the first registration request acquire the lock, but then don't release the lock as long as any other registrations are in progress.
> The current lock acquisition mechanism based on an OperationStepHandler acquiring the lock[1] can't do this, or at least not without having the request that acquires the lock have to wait for final completion until all other concurrent requests complete. (Doing that will likely cause problems due to that "unlucky" first slave not getting the expected final response. Plus it just smells bad.)
> A possibility is to remove the currrent lock acquisition in the OSH[1] and instead change the internal HostControllerRegistrationHandler.OperationExecutor API to expose a use-case specific method for the initial registration call.[2] The actual HostControllerRegistrationHandler.OperationExecutor impl is DomainModelControllerService, which is the service that installs the ModelControllerImpl and potentially has closer access to its non-public API (i.e. the locking methods.) So DomainModelControllerService can perhaps therefore coordinate the locking, holding the lock until all active registrations complete.
> [1] https://github.com/wildfly/wildfly-core/blob/master/host-controller/src/m...
> [2] I want to change that API anyway. See TODO at https://github.com/wildfly/wildfly-core/blob/master/host-controller/src/m...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFCORE-919) Allow read-only data/content storage
by James Livingston (JIRA)
[ https://issues.jboss.org/browse/WFCORE-919?page=com.atlassian.jira.plugin... ]
James Livingston updated WFCORE-919:
------------------------------------
Description:
It would be nice to allow the content repository to be read-only, if there was an external guarantee that all content should be there. This would be useful in situations where all HCs (including the DC) share that over NFS, or deployments are managed via another system (docker, puppet etc).
It could be a ContentRepository implementation which does not make chances, and fails if attempted or content is missing. On read-only HCs the current writeability check would need to be disabled, along with the cleaner task, and the DC (if it could write) would need to ensure content was not removed prior to HCs performing undeployment.
This would presumably have some interaction with WFCORE-310.
was:
It would be nice to allow the content repository to be read-only, if there was an external guarantee that all content should be there. This would be useful in situations where all HCs (including the DC) share that over NFS, or deployments are managed via another system (docker, puppet etc).
It could be a ContentRepository implementation which does not make chances, and fails if attempted or content is missing. On read-only HCs the current writeability check would need to be disabled, along with the cleaner task, and the DC (if it could write) would need to ensure content was not removed prior to HCs performing undeployment.
> Allow read-only data/content storage
> ------------------------------------
>
> Key: WFCORE-919
> URL: https://issues.jboss.org/browse/WFCORE-919
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Affects Versions: 2.0.0.Beta4
> Reporter: James Livingston
> Assignee: Brian Stansberry
>
> It would be nice to allow the content repository to be read-only, if there was an external guarantee that all content should be there. This would be useful in situations where all HCs (including the DC) share that over NFS, or deployments are managed via another system (docker, puppet etc).
> It could be a ContentRepository implementation which does not make chances, and fails if attempted or content is missing. On read-only HCs the current writeability check would need to be disabled, along with the cleaner task, and the DC (if it could write) would need to ensure content was not removed prior to HCs performing undeployment.
> This would presumably have some interaction with WFCORE-310.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFCORE-919) Allow read-only data/content storage
by James Livingston (JIRA)
James Livingston created WFCORE-919:
---------------------------------------
Summary: Allow read-only data/content storage
Key: WFCORE-919
URL: https://issues.jboss.org/browse/WFCORE-919
Project: WildFly Core
Issue Type: Feature Request
Components: Domain Management
Affects Versions: 2.0.0.Beta4
Reporter: James Livingston
Assignee: Brian Stansberry
It would be nice to allow the content repository to be read-only, if there was an external guarantee that all content should be there. This would be useful in situations where all HCs (including the DC) share that over NFS, or deployments are managed via another system (docker, puppet etc).
It could be a ContentRepository implementation which does not make chances, and fails if attempted or content is missing. On read-only HCs the current writeability check would need to be disabled, along with the cleaner task, and the DC (if it could write) would need to ensure content was not removed prior to HCs performing undeployment.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (JGRP-1954) SWIFT_PING discovery protocol fatal error on OpenStack Kilo
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1954?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1954:
---------------------------
Fix Version/s: 3.6.5
Hi Nick,
a pull request or patch would be very welcome !
> SWIFT_PING discovery protocol fatal error on OpenStack Kilo
> -----------------------------------------------------------
>
> Key: JGRP-1954
> URL: https://issues.jboss.org/browse/JGRP-1954
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.4
> Environment: JGroups client running on Mac OS X - Yosemite
> JDK 1.7.71
> OpenStack Kilo
> Reporter: Nick Sawadsky
> Assignee: Bela Ban
> Fix For: 3.6.5
>
>
> I'm attempting to use the SWIFT_PING discovery protocol on the most recent version of OpenStack, "Kilo". An error occurs during initialization of the protocol stack, the stack trace is provided below.
> The problem appears to be that support for XML-formatted responses has been removed in the OpenStack Identity API (http://developer.openstack.org/api-ref-identity-v2.html). Even though SWIFT_PING sends an Accept header of application/xml, the response still comes back as JSON (around line 286 of SWIFT_PING.java).
> I've been able to repro the issue using Postman in Chrome. I tried providing the *request* in XML , with a Content-Type header of application/xml, but Swift returns an error: "Expecting to find application/json in Content-Type header".
> It seems like the resolution would be for SWIFT_PING to be modified so it can parse the JSON response that it is receiving. If that sounds like a reasonable approach, I can try to create a patch that fixes the issue.
> Stack Trace:
> 2015-08-21 14:30:16,123 FATAL [com.pingidentity.common.util.ErrorHandler] Problem creating factory for multiplexed cluster communications
> org.xml.sax.SAXParseException: Content is not allowed in prolog.
> at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:257) ~[?:1.8.0_25]
> at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:348) ~[?:1.8.0_25]
> at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121) ~[?:1.8.0_25]
> at org.jgroups.protocols.SWIFT_PING$Keystone_V_2_0_Auth.authenticate(SWIFT_PING.java:307) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.protocols.SWIFT_PING$SwiftClient.authenticate(SWIFT_PING.java:443) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.protocols.SWIFT_PING.init(SWIFT_PING.java:68) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:860) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.JChannel.init(JChannel.java:854) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.JChannel.<init>(JChannel.java:159) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.JChannel.<init>(JChannel.java:120) ~[jgroups.jar:3.6.4.Final]
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months