Seen in a failover-singleton-deployment-jvmkill-random-election-policy scenario:

Timeline:

• In the beginning of the test, perf18 is elected as a singleton provider.
• perf18 is killed
• other nodes receive a new cluster view
• perf19 is elected as a new singleton provider - so far so good

  [JBossINF] [0m[0m09:56:11,250 INFO  [org.wildfly.clustering.server] (DistributedSingletonService - 1) WFLYCLSV0003: perf19 elected as the singleton provider of the jboss.deployment.unit."clusterbench-ee7-singleton-jbossall.ear".FIRST_MODULE_USE service
  

• from now on, it's starts to be interesting: JBEAP-2254 occurs on perf19, perf19 leaves cluster, the deployment is stopped on perf19

  [JBossINF] [0m[33m09:56:11,259 WARN  [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000004: Failure during stop of service jboss.deployment.subunit."clusterbench-ee7-singleton-jbossall.ear"."clusterbench-ee7-ejb.jar".FIRST_MODULE_USE.service: java.lang.IllegalStateException
  

• perf21 is elected as a new singleton provider, JBEAP-2254 occurs on perf21, perf21 leaves cluster, the deployment is stopped on perf21
• perf20 is elected as a new singleton provider, JBEAP-2254 occurs on perf20, perf20 is the only node left in a cluster, the deployment is stopped on perf20
• perf20 is elected again and now the deployment successfully starts
• perf21 and perf19 rejoin cluster
• test continues

Logs:
http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-failover-singleton-deployment-jvmkill-random-election-policy/12/console-perf19/
http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-failover-singleton-deployment-jvmkill-random-election-policy/12/console-perf20/
http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-failover-singleton-deployment-jvmkill-random-election-policy/12/console-perf21/