[JBoss JIRA] (AS7-5567) Resolve AS7/OSGi disconnects
by Thomas Diesler (JIRA)
Thomas Diesler created AS7-5567:
-----------------------------------
Summary: Resolve AS7/OSGi disconnects
Key: AS7-5567
URL: https://issues.jboss.org/browse/AS7-5567
Project: Application Server 7
Issue Type: Task
Components: OSGi, Server
Reporter: Thomas Diesler
Assignee: Thomas Diesler
An umbrella issue that collects tasks that need to be resolved to improve (or make it even work) OSGi/AS7 integration
#1 Framework Startup
At Framework startup a number bootstrap and persistent bundles (from a former run) need to be deployed before the Framework reaches its ACTIVE state. This cannot be modelled with service dependencies because must be possible to uninstall the persistent bundles without taking the Framework down. Tracked by AS7-5365
#2 Defer Resolution Phase
It is a MUST HAVE requirement that the user can deploy a large set of bundles in an arbitrary order. In OSGi we talk about a bundle states like
* INSTALLED (metadata is known and valid)
* RESOLVED (wiring is available, classes can get loaded)
* ACTIVE (services that the bundle provides have started)
Currently, any deployment running through the chain of deployment unit processors get a module created and a classloader associated. DUPs in the following phases assume that a classloader is available, which is currently not the case for unresolved bundles.
This simplistic approach causes an ordering issue and does not work with OSGi bundles. Here it must be possible to install multiple bundles before the set can be resolved. Technically, bundle deployment must stop before the module phase and resume when bundle resolution is triggered. If this is done, the following DUPs can correctly assume that a classloader is available. Tracked by AS7-5477
#3 Deployment Properties
It is a MUST HAVE requirement that users can associate properties with a bundle deployment. This would for example be a bundle start-level or an auto-start flag that determines whether a bundle deployment should automatically resolve/start. This issue is a dependency of #2. On a technical level this needs to be supported by the management API and later by the higher levels (i.e. console & cli). Tracked by AS7-3694
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (JBRULES-3528) Deadlock when using pseudo session clock
by Cyril Sochor (JIRA)
Cyril Sochor created JBRULES-3528:
-------------------------------------
Summary: Deadlock when using pseudo session clock
Key: JBRULES-3528
URL: https://issues.jboss.org/browse/JBRULES-3528
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core (fusion)
Affects Versions: 5.4.0.Final, 5.3.0.Final
Reporter: Cyril Sochor
Assignee: Mark Proctor
Deadlock when using fireUntilHalt in one thread and PseudoClockScheduler.advanceTime() in second thread.
Surroundings:
I read many events from JMS queue, each event has timestamp. I need temporal operations measured by time in timestamps. E.g. SomeEvent() over window:time(10s) means events with timestamps in interval 10s, not events inserted in interval 10s. So, I must use pseudo session clock and advance time before event insert into statefull session. Sometimes deadlock occured or NullPointerException is thrown.
I created test case.
Deadlock stacktraces:
Name: Thread-1
State: BLOCKED on org.drools.time.impl.PseudoClockScheduler@4599d5b owned by: Thread-0
Total blocked: 6 Total waited: 3
Stack trace:
org.drools.time.impl.PseudoClockScheduler.getCurrentTime(PseudoClockScheduler.java:104)
org.drools.common.AbstractWorkingMemory.endOperation(AbstractWorkingMemory.java:1345)
org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1240)
- locked org.drools.common.DefaultAgenda@57e2793d
org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1126)
org.drools.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1327)
org.drools.common.AbstractWorkingMemory.fireUntilHalt(AbstractWorkingMemory.java:754)
- locked org.drools.reteoo.ReteooStatefulSession@31d8d237
org.drools.common.AbstractWorkingMemory.fireUntilHalt(AbstractWorkingMemory.java:730)
org.drools.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:245)
org.drools.integrationtests.StreamsTest$1.run(StreamsTest.java:526)
java.lang.Thread.run(Thread.java:662)
Name: Thread-0
State: BLOCKED on org.drools.common.DefaultAgenda@57e2793d owned by: Thread-1
Total blocked: 2 Total waited: 0
Stack trace:
org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1168)
org.drools.common.Scheduler$ActivationTimerJob.execute(Scheduler.java:86)
org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:47)
org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:1)
org.drools.time.impl.PseudoClockScheduler.runCallBacks(PseudoClockScheduler.java:203)
org.drools.time.impl.PseudoClockScheduler.advanceTime(PseudoClockScheduler.java:156)
- locked org.drools.time.impl.PseudoClockScheduler@4599d5b
org.drools.integrationtests.StreamsTest.processStocks(StreamsTest.java:533)
org.drools.integrationtests.StreamsTest.testEvenFirePseudoClockRulesAB(StreamsTest.java:500)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
org.junit.internal.runners.statements.FailOnTimeout$1.run(FailOnTimeout.java:28)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (AS7-5508) Activation of OSGi causes missing/unsatisfied service dependencies
by Thomas Diesler (JIRA)
Thomas Diesler created AS7-5508:
-----------------------------------
Summary: Activation of OSGi causes missing/unsatisfied service dependencies
Key: AS7-5508
URL: https://issues.jboss.org/browse/AS7-5508
Project: Application Server 7
Issue Type: Bug
Components: OSGi, Server
Reporter: Thomas Diesler
Assignee: Thomas Diesler
Activating OSGi through management op (console/cli) will get
{code}
13:15:06,192 INFO [org.jboss.osgi.framework] (MSC service thread 1-3) JBOSGI011006: OSGi Framework - 2.0.0.CR21
13:15:06,561 INFO [org.jboss.osgi.framework] (MSC service thread 1-1) JBOSGI011001: Bundle installed: org.apache.felix.configadmin:1.2.8
13:15:06,562 INFO [org.jboss.osgi.framework] (MSC service thread 1-2) JBOSGI011001: Bundle installed: org.apache.felix.log:1.0.0
13:15:06,563 INFO [org.jboss.osgi.framework] (MSC service thread 1-4) JBOSGI011001: Bundle installed: jboss-osgi-logging:1.0.0
13:15:06,565 INFO [org.jboss.osgi.framework] (MSC service thread 1-3) JBOSGI011001: Bundle installed: jboss-as-osgi-configadmin:7.2.0.Alpha1-SNAPSHOT
13:15:06,739 INFO [org.jboss.as.controller] (MSC service thread 1-2) JBAS014774: Service status report
JBAS014775: New missing/unsatisfied dependencies:
service jbosgi.integration.BootstrapBundles.COMPLETE (missing) dependents: [service jbosgi.internal.framework.INIT, service jbosgi.integration.PersistentBundles.INSTALL, service jboss.osgi.as.module.registration]
service jbosgi.integration.PersistentBundles.COMPLETE (missing) dependents: [service jbosgi.internal.framework.INIT]
13:15:06,758 INFO [org.jboss.osgi.framework] (MSC service thread 1-4) JBOSGI011011: Starting bundles for start level: 1
13:15:06,778 INFO [org.jboss.osgi.framework] (MSC service thread 1-4) JBOSGI011002: Bundle started: jboss-osgi-logging:1.0.0
13:15:06,791 INFO [org.jboss.osgi.framework] (MSC service thread 1-4) JBOSGI011002: Bundle started: jboss-as-osgi-configadmin:7.2.0.Alpha1-SNAPSHOT
13:15:06,816 INFO [org.jboss.osgi.framework] (MSC service thread 1-4) JBOSGI011002: Bundle started: org.apache.felix.log:1.0.0
13:15:06,864 INFO [org.jboss.osgi.framework] (MSC service thread 1-4) JBOSGI011002: Bundle started: org.apache.felix.configadmin:1.2.8
13:15:06,867 INFO [org.jboss.osgi.framework] (MSC service thread 1-4) JBOSGI011000: OSGi Framework started
13:15:06,887 INFO [org.jboss.web] (MSC service thread 1-1) JBAS018210: Register web context: /httpservice
13:15:06,905 INFO [org.jboss.as.controller] (MSC service thread 1-3) JBAS014774: Service status report
JBAS014776: Newly corrected services:
service jbosgi.integration.BootstrapBundles.COMPLETE (no longer required)
service jbosgi.integration.PersistentBundles.COMPLETE (no longer required)
{code}
This is related to AS7-5365 but now easily re-producable in master. More background is given here
https://community.jboss.org/wiki/OSGiSubsystemActivationProcess
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (AS7-5320) Intermittent failure in RestEasyIntegrationTestCase
by Kabir Khan (JIRA)
Kabir Khan created AS7-5320:
-------------------------------
Summary: Intermittent failure in RestEasyIntegrationTestCase
Key: AS7-5320
URL: https://issues.jboss.org/browse/AS7-5320
Project: Application Server 7
Issue Type: Feature Request
Reporter: Kabir Khan
Assignee: Thomas Diesler
Priority: Critical
Fix For: 7.2.0.Alpha1
org.jboss.as.test.integration.osgi.jaxrs.RestEasyIntegrationTestCase.org.jboss.as.test.integration.osgi.jaxrs.RestEasyIntegrationTestCase
Failing for the past 1 build (Since #4631 )
Took 1 sec.
add description
Error Message
Cannot deploy: jaxrs-osgi-target
Stacktrace
org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: jaxrs-osgi-target
at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:83)
at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64)
at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46)
at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:145)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80)
at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:182)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
Standard Output
[0m06:36:14,314 INFO [org.jboss.as.repository] (management-handler-thread - 3) JBAS014900: Content added at location /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/basic/target/jbossas/standalone/data/content/75/39124d9f1c4c8cdd55cb6bc684c6475deaa113/content
[0m[0m06:36:14,320 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "jaxrs-osgi-target"
[0m[0m06:36:14,366 INFO [org.jboss.osgi.framework] (MSC service thread 1-6) JBOSGI011006: OSGi Framework - 2.0.0.CR15
[0m[0m06:36:14,694 INFO [org.jboss.osgi.framework] (MSC service thread 1-1) JBOSGI011001: Bundle installed: jboss-as-osgi-configadmin:7.2.0.Alpha1-SNAPSHOT
[0m[0m06:36:14,713 INFO [org.jboss.osgi.framework] (MSC service thread 1-3) JBOSGI011001: Bundle installed: jboss-osgi-logging:1.0.0
[0m[0m06:36:14,733 INFO [org.jboss.osgi.framework] (MSC service thread 1-5) JBOSGI011001: Bundle installed: org.apache.felix.log:1.0.0
[0m[0m06:36:14,798 INFO [org.jboss.osgi.framework] (MSC service thread 1-6) JBOSGI011001: Bundle installed: org.apache.felix.configadmin:1.2.8
[0m[0m06:36:15,029 INFO [org.jboss.as.server] (management-handler-thread - 3) JBAS015870: Deploy of deployment "jaxrs-osgi-target" was rolled back with failure message {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.jaxrs-osgi-target.REGISTER Missing[JBAS014861: <one or more transitive dependencies>]","jbosgi.integration.PersistentBundles.INSTALL Missing[JBAS014861: <one or more transitive dependencies>]"]}
[0m[0m06:36:15,036 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment jaxrs-osgi-target in 6ms
[0m
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (JGRP-1401) RELAY: messages lost when relay coordinator crashes
by Bela Ban (Created) (JIRA)
RELAY: messages lost when relay coordinator crashes
---------------------------------------------------
Key: JGRP-1401
URL: https://issues.jboss.org/browse/JGRP-1401
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.1
When we have sites {A,B,C} and {X,Y,Z} (with relay coords A and X), during the time X leaves (or crashes) and Y taking over, all messages sent by the first site are not relayed to the second site.
Because the sites are autonomous, there won't be any retransmission of the dropped messages.
This can have an adverse affect, e.g. in Infinispan:
- Say key K is stored on A, B and Z
- Now we're updating K, on A and B, but before the change is relayed to the other site, X crashes
- If there is no rebalancing, e.g. because K is still to be stored on A, B and Z, since the update on Z was dropped, Z has a stale value !
SOLUTION 1:
- Have a backup coordinator B cache the last N messages in memory (with overflow to disk)
- A numbers relayed messages
- As soon as A has relayed message #50, it sends this info to B. Or, alternatively, this could be done periodically, or based on the number of relayed messages (e.g. every 10 messages)
- B can then purge those messages
- When A crashes, B runs a reconciliation protocol with X to determine whether to relay some backed up messages
- C now starts acting as backup relay to B
This solution is probably the simplest to implement, and doesn't require any code changes in Infinispan. However, there is still a chance of message loss if both the relay *and* the backup relay crash at the same time.
SOLUTION 2:
- After a crash (not a graceful leave !) of a relay coordinator, there has to be a full rebalancing of all keys
- This is wasteful though
- May not be needed, perhaps Infinispan could check whether a full rebalancing is required ?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (AS7-5365) Intermittent failure due to missing OSGi service
by Thomas Diesler (JIRA)
Thomas Diesler created AS7-5365:
-----------------------------------
Summary: Intermittent failure due to missing OSGi service
Key: AS7-5365
URL: https://issues.jboss.org/browse/AS7-5365
Project: Application Server 7
Issue Type: Bug
Components: OSGi, Server
Reporter: Thomas Diesler
Assignee: Thomas Diesler
Fix For: 7.2.0.CR1
For the first OSGi related deployments we intermittently see
{code}
JBAS015870: Deploy of deployment "webapp.war" was rolled back with failure message {"JBAS014771: Services with missing/unavailable dependencies" => ["jbosgi.integration.PersistentBundles.INSTALL Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.unit.\"webapp.war\".REGISTER Missing[JBAS014861: <one or more transitive dependencies>]"]}
{code}
which is due to a race condition at subsystem startup.
h4. Background
At startup the framework goes through various phases
# Framework.CREATE
# Framework.INIT
# Framework.ACTIVE
During framework INIT persistent bundles (i.e. from a former run) are installed/started according to their persistent settings.
In terms of services it means that the Framework.INIT service may depend on a number of Bundle.INSTALLED or Bundle.ACTIVE services. This however cannot be modelled as service dependencies because it must be possible to uninstall a persistent bundle (i.e. remove the Bundle.INSTALL) service without taking the framework down.
Currently, we use a ServiceListener for the persistent Bundle services and install a PersistentBundles.COMPLETE service that Framework.INIT can actually depend on.
There is currently no guarantee that the PersistentBundles.COMPLETE service gets installed (and as a consequence that the Framework.INIT starts up) before the OSGi deployment does its phase checking for missing services.
AFAICS, there is currently no way to model this type of dependency properly without having this race condition.
A possible solution may be a notion of DependencyType.WEAK. The semantic would be a required dependency that can go away once the target service has reached its target state (or has failed)
h4. Example
* serviceA depends on serviceB with DependencyType.WEAK
* serviceA starts when serviceB has started
* serviceA stays UP when serviceB gets removed
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (AS7-5497) Exception handling of EJB container for MDB is incorrect
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/AS7-5497?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas resolved AS7-5497.
---------------------------------
Fix Version/s: 7.1.3.Final (EAP)
7.2.0.Alpha1
Resolution: Done
> Exception handling of EJB container for MDB is incorrect
> --------------------------------------------------------
>
> Key: AS7-5497
> URL: https://issues.jboss.org/browse/AS7-5497
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: 7.1.2.Final (EAP)
> Environment: JBoss EAP 6.0.0
> Reporter: Adam Kovari
> Assignee: JBoss SET
> Priority: Minor
> Labels: eap6, ejb3.1
> Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1
>
>
> After deploying a MDB with Container-Managed transaction and
> TransactionAttribute NOT_SUPPORTED, a RuntimeException thrown from
> within the MDB onMessage() is reported to the Adapter as such, with no
> EJBException wrapping. I.e.: the "((javax.jms.MessageListener)
> endPoint).onMessage(message)" call in our adapter fails with the
> exception type originally thrown.
> This does not look compliant with EJB 3.1 spec(JSR 318: Enterprise
> JavaBeansTM, Version 3.1, Table 20 page 392, last cell bottom right):
> "Throw EJBException that wraps the original exception to resource
> adapter".
> Another part of spec I was just made aware of says this:
> p383 of the spec states -
> In the case of a message-driven bean, the container logs the exception and then throws a javax.ejb.EJBException that wraps the original exception to the resource adapter. (See [15]).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months