[JBoss JIRA] (ISPN-3764) ISPN testsuite fails for RHEL6x64 && IBM JDK6
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3764?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-3764:
----------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/2324/files (was: chttps://github.com/infinispan/infinispan/pull/2324/files)
> ISPN testsuite fails for RHEL6x64 && IBM JDK6
> ----------------------------------------------
>
> Key: ISPN-3764
> URL: https://issues.jboss.org/browse/ISPN-3764
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Affects Versions: 6.0.0.Final
> Environment: RHEL6x64 IBM6
> Reporter: Vitalii Chepeliuk
> Assignee: William Burns
> Priority: Critical
> Labels: 620, testsuite_stability
>
> Sometimes build is stucked and sometiemes it throws following exception when CORE module is running
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !!!!!! (testng-DistWriteSkewTest) Exiting because DistWriteSkewTest has NOT shut down all the cache managers it has started !!!!!!!
> !!!!!! (testng-DistWriteSkewTest) See allocation stacktrace to find out where still-running cacheManager was created: !!!!!!!
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> java.lang.Throwable
> at org.infinispan.test.fwk.TestCacheManagerFactory.addThreadCacheManager(TestCacheManagerFactory.java:373)
> at org.infinispan.test.fwk.TestCacheManagerFactory.newDefaultCacheManager(TestCacheManagerFactory.java:356)
> at org.infinispan.test.fwk.TestCacheManagerFactory.newDefaultCacheManager(TestCacheManagerFactory.java:68)
> at org.infinispan.test.fwk.TestCacheManagerFactory.createClusteredCacheManager(TestCacheManagerFactory.java:160)
> at org.infinispan.test.fwk.TestCacheManagerFactory.createClusteredCacheManager(TestCacheManagerFactory.java:151)
> at org.infinispan.test.fwk.TestCacheManagerFactory.createClusteredCacheManager(TestCacheManagerFactory.java:125)
> at org.infinispan.test.MultipleCacheManagersTest.addClusterEnabledCacheManager(MultipleCacheManagersTest.java:177)
> at org.infinispan.test.MultipleCacheManagersTest.addClusterEnabledCacheManager(MultipleCacheManagersTest.java:162)
> at org.infinispan.test.MultipleCacheManagersTest.createCluster(MultipleCacheManagersTest.java:196)
> at org.infinispan.container.versioning.AbstractClusteredWriteSkewTest.createCacheManagers(AbstractClusteredWriteSkewTest.java:59)
> at org.infinispan.test.MultipleCacheManagersTest.callCreateCacheManagers(MultipleCacheManagersTest.java:69)
> at org.infinispan.test.MultipleCacheManagersTest.createBeforeMethod(MultipleCacheManagersTest.java:79)
> at sun.reflect.GeneratedMethodAccessor151.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> Add link to jenkins job
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
--
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
[JBoss JIRA] (ISPN-3878) Unhandled failing ST cancel leads to deadlock
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3878?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3878:
------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Unhandled failing ST cancel leads to deadlock
> ---------------------------------------------
>
> Key: ISPN-3878
> URL: https://issues.jboss.org/browse/ISPN-3878
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 6.0.1.Final
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 7.0.0.Alpha1, 7.0.0.Final
>
>
> Two concurrent rebalances can lead to deadlock. Example situation when two rebalances can be executed in parallel is when the coordinator is leaving a cluster; it sends REBALANCE_START and passes away. Then, the new coordinator recovers cluster status and sends REBALANCE_START as well.
> 1. Node is requesting segments for the old topology, StateConsumerImpl.isTransferThreadRunning is set to true
> 2. Node waits for StateResponseCommand in SCI: InboundTransferTask.awaitCompletion()
> 3. New rebalance is started, changing the CH - requested segment is not in the new CH
> 4. Some ST are canceled, the cancel command is sent and taking a long time
> 5. StateReponseCommand is received, but in SCI.applyState it is found out that this segment is no longer owned so the task is not completed/cancelled
> 6. Later, we get TimeoutException from InboundTransferTask.sendCancelCommand, and no more cancellations are executed
> Result: the inbound transfer thread is stuck and rebalance is never completed.
--
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
[JBoss JIRA] (ISPN-1790) Release script should not rip off comments from POM.XML files
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-1790?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-1790:
---------------------------------------
AFAIK Manik mentioned it was caused by the python scripts editing the XML file.
> Release script should not rip off comments from POM.XML files
> -------------------------------------------------------------
>
> Key: ISPN-1790
> URL: https://issues.jboss.org/browse/ISPN-1790
> Project: Infinispan
> Issue Type: Enhancement
> Components: Build process
> Affects Versions: 5.1.0.FINAL
> Reporter: Sanne Grinovero
> Assignee: Manik Surtani
> Priority: Minor
> Labels: release.py
>
> Comparing the git commit which was used to release 5.1.0.Final to the final tag of the released version, reveals some changes which are likely unintended:
> * All Copyright statements removed
> * All comments removed (useful and unuseful)
> * In some way changed the inlined scripts for Google analytics - not sure if it's still working
--
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
[JBoss JIRA] (ISPN-3882) Recovery documentation is incorrect
by Mircea Markus (JIRA)
Mircea Markus created ISPN-3882:
-----------------------------------
Summary: Recovery documentation is incorrect
Key: ISPN-3882
URL: https://issues.jboss.org/browse/ISPN-3882
Project: Infinispan
Issue Type: Feature Request
Reporter: Mircea Markus
Assignee: Mircea Markus
<snip>
3.5. Cache Loaders and transactional caches
When a cache is transactional and a cache loader is present, the cache loader won’t be enlisted in the transaction in which the cache is part. That means that it is possible to have inconsistencies at cache loader level: the transaction to succeed applying the in-memory state but (partially) fail applying the changes to the store. Manual recovery would not work with caches stores.
</snip>
The manual recovery should work with cache stores as well. A test - if missing - needs to be added to confirm this.
--
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
[JBoss JIRA] (ISPN-3882) Recovery documentation is incorrect
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3882?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3882:
--------------------------------
Component/s: Documentation
> Recovery documentation is incorrect
> -----------------------------------
>
> Key: ISPN-3882
> URL: https://issues.jboss.org/browse/ISPN-3882
> Project: Infinispan
> Issue Type: Feature Request
> Components: Documentation
> Reporter: Mircea Markus
> Assignee: Mircea Markus
>
> <snip>
> 3.5. Cache Loaders and transactional caches
> When a cache is transactional and a cache loader is present, the cache loader won’t be enlisted in the transaction in which the cache is part. That means that it is possible to have inconsistencies at cache loader level: the transaction to succeed applying the in-memory state but (partially) fail applying the changes to the store. Manual recovery would not work with caches stores.
> </snip>
> The manual recovery should work with cache stores as well. A test - if missing - needs to be added to confirm this.
--
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
[JBoss JIRA] (ISPN-3457) Infinispan error running on IBM JDK
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3457?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-3457:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 6.0.0.Final
(was: 6.0.0.Alpha3)
Resolution: Duplicate Issue
> Infinispan error running on IBM JDK
> -----------------------------------
>
> Key: ISPN-3457
> URL: https://issues.jboss.org/browse/ISPN-3457
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 6.0.0.Alpha3
> Environment: WAS 8.0.0.6 JDK, Windows 7 Professional
> Reporter: Luis Montoya
> Assignee: Mircea Markus
> Fix For: 6.0.0.Final
>
>
> I created a sample application using infinispan on standar JDK (Sun/Oracle). This app works fine using this JDK.
>
> I tried to run the app on IBM JDK (the needed for WAS), but I get the below error:
>
> org.infinispan.commons.CacheException: Unable to construct a GlobalComponentRegistry!
> at org.infinispan.factories.GlobalComponentRegistry.<init>(GlobalComponentRegistry.java:129)
> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:276)
> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:246)
> at org.infinispan.quickstart.clusteredcache.replication.AbstractNode.createCacheManagerProgramatically(AbstractNode.java:41)
> at org.infinispan.quickstart.clusteredcache.replication.AbstractNode.<init>(AbstractNode.java:62)
> at org.infinispan.quickstart.clusteredcache.replication.Node0.main(Node0.java:32)
> Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.topology.LocalTopologyManagerImpl.inject(org.infinispan.remoting.transport.Transport,java.util.concurrent.ExecutorService,org.infinispan.factories.GlobalComponentRegistry,org.infinispan.util.TimeService) on object of type LocalTopologyManagerImpl with parameters [org.infinispan.executors.LazyInitializingExecutorService@96d7b55b, org.infinispan.executors.LazyInitializingExecutorService@96d7b55b, org.infinispan.factories.GlobalComponentRegistry@9fd5a559, org.infinispan.util.DefaultTimeService@725adace]
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:188)
> at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:229)
> at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:65)
> at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:797)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:201)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:156)
> at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:277)
> at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:253)
> at org.infinispan.factories.GlobalComponentRegistry.<init>(GlobalComponentRegistry.java:125)
> ... 5 more
> Caused by: java.lang.IllegalArgumentException: discrepancia en el tipo de argumento
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:600)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
> ... 13 more
>
>
> It seems that a method which is being invoked through reflection is receiving incorrectly the first parameter, which should be a org.infinispan.remoting.transport.Transport instance, but it is receiving a org.infinispan.executors.LazyInitializingExecutorService@96d7b55b instance
>
> The code which launch the error is the next:
>
>
> new DefaultCacheManager(
> GlobalConfigurationBuilder.defaultClusteredBuilder().globalJmxStatistics().allowDuplicateDomains(true)
> .transport().addProperty("configurationFile", "jgroups.xml")
> .build(),
> new ConfigurationBuilder()
> .clustering().cacheMode(CacheMode.REPL_SYNC)
> .build()
> );
> Making a review and debug of the code, the next behavior was seen which produce the error:
> if a map called map contains something like this {1=some.class.type}, and you try to get a value using the 0 as the key ( map.get(0), it doens't return null rather it returns the value for the 1 key, it means, for map.get(0) it returns "some.class.type", as if map.get(1) was called)
> Also, when the contains method of Map interface is called ( map.contains(0)), it returns true, which is incorrect because the map only has the 1 key
> This behavior is happening on this class and method:
> class: org.infinispan.factories.components.ComponentMetadata$InjectMetadata
> methods: getParameterName, isParameterNameSet
--
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
[JBoss JIRA] (ISPN-1541) NotifyingNotifiableFuture's FutureListener can not invoke Future API on FutureListener#futureDone callback
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-1541?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-1541:
-----------------------------------
I believe that the synchronization between notifyDone() and setNetworkFuture has to be done internally in NotifyingFutureImpl and that the notifyDone() interface should be enriched by the actual return value.
> NotifyingNotifiableFuture's FutureListener can not invoke Future API on FutureListener#futureDone callback
> ----------------------------------------------------------------------------------------------------------
>
> Key: ISPN-1541
> URL: https://issues.jboss.org/browse/ISPN-1541
> Project: Infinispan
> Issue Type: Bug
> Components: RPC
> Affects Versions: 5.0.1.FINAL, 5.1.0.BETA4
> Reporter: Vladimir Blagojevic
> Assignee: Vladimir Blagojevic
> Fix For: 5.1.0.CR1
>
>
> Invoking Future#get from a FutureListener attached to a NotifyingNotifiableFuture passed as a parameter to RpcManager#invokeRemotelyInFuture throws InterruptedException! Sounds more complicated than it really is! In another words, the following code throws InterruptedException
> {code}NotifyingFutureImpl f = ...
> f.attachListener(new FutureListener<Object>() {
>
> @Override
> public void futureDone(Future<Object> future) {
> try {
> future.get();
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> });
> CommandsFactory cf = cache1.getAdvancedCache().getComponentRegistry().getComponent(CommandsFactory.class);
> cache1.getAdvancedCache().getRpcManager().invokeRemotelyInFuture(null, cf.buildPutKeyValueCommand("k","v", -1, -1, null), f);
> {code}
> the reason why we get InterruptedException is that we invoke notifyDone which in turn invokes futureDone from the same thread invoking the future's callable. In effect we invoke future#get on the same *the same thread* that is running the callable for the associated future!
> {code}
> public final void invokeRemotelyInFuture(final Collection<Address> recipients, final ReplicableCommand rpc, final boolean usePriorityQueue, final NotifyingNotifiableFuture<Object> l, final long timeout) {
> if (trace) log.tracef("%s invoking in future call %s to recipient list %s", t.getAddress(), rpc, recipients);
> final CountDownLatch futureSet = new CountDownLatch(1);
> Callable<Object> c = new Callable<Object>() {
> public Object call() throws Exception {
> Object result = null;
> try {
> result = invokeRemotely(recipients, rpc, true, usePriorityQueue, timeout);
> } finally {
> try {
> futureSet.await();
> } catch (InterruptedException e) {
> Thread.currentThread().interrupt();
> } finally {
> l.notifyDone();
> }
> }
> return result;
> }
> };
> l.setNetworkFuture(asyncExecutor.submit(c));
> futureSet.countDown();
> }
> {code}
> The solution is to wait for callable to finish and invoke notifyDone from the other thread. We have two choices here:
> a) invoke notifyDone from the same thread invoking invokeRemotelyInFuture. This in turn changes invokeRemotelyInFuture to be less async than it should be
> b) invoke callback on another thread
> {code}
> public final void invokeRemotelyInFuture(final Collection<Address> recipients,
> final ReplicableCommand rpc, final boolean usePriorityQueue,
> final NotifyingNotifiableFuture<Object> l, final long timeout) {
> if (trace)
> log.tracef("%s invoking in future call %s to recipient list %s", t.getAddress(), rpc,
> recipients);
> final CountDownLatch callableCompleted = new CountDownLatch(1);
> Callable<Object> c = new Callable<Object>() {
> public Object call() throws Exception {
> Object result = null;
> try {
> result = invokeRemotely(recipients, rpc, true, usePriorityQueue, timeout);
> } finally {
> callableCompleted.countDown();
> }
> return result;
> }
> };
> l.setNetworkFuture(asyncExecutor.submit(c));
> asyncExecutor.submit(new Runnable() {
>
> @Override
> public void run() {
> try {
> callableCompleted.await();
> } catch (Exception e) {
> } finally {
> l.notifyDone();
> }
> }
> });
> }
> {code}
> We can of course, leave things as they are right now but in such case we have to warn the implementer of FutureListener that he/she can not call future.get() from a FutureListener!
--
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
[JBoss JIRA] (ISPN-1541) NotifyingNotifiableFuture's FutureListener can not invoke Future API on FutureListener#futureDone callback
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-1541?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-1541:
-----------------------------------
Hi, I was looking for this in relation with ISPN-3868, but I haven't really got your solution. Now you can wait for the future.get(), but the returned value is of no use: as in replication.InvokeRemotelyInFutureTest, the returned value has to be known before, and that's not really handy for the listener. It seems there's the DeferredReturnFuture but it does not seem to me as usable (and it is not) as it will always return null.
> NotifyingNotifiableFuture's FutureListener can not invoke Future API on FutureListener#futureDone callback
> ----------------------------------------------------------------------------------------------------------
>
> Key: ISPN-1541
> URL: https://issues.jboss.org/browse/ISPN-1541
> Project: Infinispan
> Issue Type: Bug
> Components: RPC
> Affects Versions: 5.0.1.FINAL, 5.1.0.BETA4
> Reporter: Vladimir Blagojevic
> Assignee: Vladimir Blagojevic
> Fix For: 5.1.0.CR1
>
>
> Invoking Future#get from a FutureListener attached to a NotifyingNotifiableFuture passed as a parameter to RpcManager#invokeRemotelyInFuture throws InterruptedException! Sounds more complicated than it really is! In another words, the following code throws InterruptedException
> {code}NotifyingFutureImpl f = ...
> f.attachListener(new FutureListener<Object>() {
>
> @Override
> public void futureDone(Future<Object> future) {
> try {
> future.get();
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> });
> CommandsFactory cf = cache1.getAdvancedCache().getComponentRegistry().getComponent(CommandsFactory.class);
> cache1.getAdvancedCache().getRpcManager().invokeRemotelyInFuture(null, cf.buildPutKeyValueCommand("k","v", -1, -1, null), f);
> {code}
> the reason why we get InterruptedException is that we invoke notifyDone which in turn invokes futureDone from the same thread invoking the future's callable. In effect we invoke future#get on the same *the same thread* that is running the callable for the associated future!
> {code}
> public final void invokeRemotelyInFuture(final Collection<Address> recipients, final ReplicableCommand rpc, final boolean usePriorityQueue, final NotifyingNotifiableFuture<Object> l, final long timeout) {
> if (trace) log.tracef("%s invoking in future call %s to recipient list %s", t.getAddress(), rpc, recipients);
> final CountDownLatch futureSet = new CountDownLatch(1);
> Callable<Object> c = new Callable<Object>() {
> public Object call() throws Exception {
> Object result = null;
> try {
> result = invokeRemotely(recipients, rpc, true, usePriorityQueue, timeout);
> } finally {
> try {
> futureSet.await();
> } catch (InterruptedException e) {
> Thread.currentThread().interrupt();
> } finally {
> l.notifyDone();
> }
> }
> return result;
> }
> };
> l.setNetworkFuture(asyncExecutor.submit(c));
> futureSet.countDown();
> }
> {code}
> The solution is to wait for callable to finish and invoke notifyDone from the other thread. We have two choices here:
> a) invoke notifyDone from the same thread invoking invokeRemotelyInFuture. This in turn changes invokeRemotelyInFuture to be less async than it should be
> b) invoke callback on another thread
> {code}
> public final void invokeRemotelyInFuture(final Collection<Address> recipients,
> final ReplicableCommand rpc, final boolean usePriorityQueue,
> final NotifyingNotifiableFuture<Object> l, final long timeout) {
> if (trace)
> log.tracef("%s invoking in future call %s to recipient list %s", t.getAddress(), rpc,
> recipients);
> final CountDownLatch callableCompleted = new CountDownLatch(1);
> Callable<Object> c = new Callable<Object>() {
> public Object call() throws Exception {
> Object result = null;
> try {
> result = invokeRemotely(recipients, rpc, true, usePriorityQueue, timeout);
> } finally {
> callableCompleted.countDown();
> }
> return result;
> }
> };
> l.setNetworkFuture(asyncExecutor.submit(c));
> asyncExecutor.submit(new Runnable() {
>
> @Override
> public void run() {
> try {
> callableCompleted.await();
> } catch (Exception e) {
> } finally {
> l.notifyDone();
> }
> }
> });
> }
> {code}
> We can of course, leave things as they are right now but in such case we have to warn the implementer of FutureListener that he/she can not call future.get() from a FutureListener!
--
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
[JBoss JIRA] (ISPN-3881) Remove references to startserver.sh from the documentation
by Mircea Markus (JIRA)
Mircea Markus created ISPN-3881:
-----------------------------------
Summary: Remove references to startserver.sh from the documentation
Key: ISPN-3881
URL: https://issues.jboss.org/browse/ISPN-3881
Project: Infinispan
Issue Type: Feature Request
Components: Documentation
Reporter: Mircea Markus
Assignee: Tristan Tarrant
The 6.0 documentation still contains references to the startserver.sh script.
All these should be removed and replaced with a link to how the servers should be started based on WF.
--
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