Drools cache is flushed in jboss cloud provisioned environment

We have a strange issue, occurring infrequently on a cloud provisioned jboss environment. We have a cluster of jboss servers, provisioned in a private cloud environment. We have Jboss MBean implementations packaged in an ear and deployed on all the provisioned servers.
All the MBeans initialize rules (mvel) configured as drl on a remote http Apache host and are configured to poll (ResourceChangeScanner, ResourceChangeNotifier) and load new set of rules on each server using a KnowledgeAgent (private static KnowledgeAgent kagent).
Each subsequent request will create a new statefulSession (getKagent().getKnowledgeBase().newStatefulKnowledgeSession() and execute the rules and are doing a session.dispose in the end.

Everything works fine, except that on one of the jboss installations, it looks like the cached drools are flushed from memory without errors or exceptions and all subsequent executions on rules (fireAllRules()) through the stateful sessions, yield no results. Basically because there are no rules to execute.
The polling continues at a frequency of 1 hour for new rules, but there is no action, because there are no new, or modified rules (drls), but unfortunately, it looks like the cache is empty.
I don't understand how comparison happens between the cached set of rules and the ones on the resource server (http Apache server), but it neither reloads nor executes anything or throws errors or exceptions.
knowledgepackages.isEmpty() check happens and it's returns false. So no exceptions either. We are able to see that a couple of packages are present, as some rules in those are executing. I am not sure whether this packages are complete in cache, or just is not empty. We are trying to put more checks to see if each of the knowledgePackages are empty (.rules.isEmpty()), as that's what it seems to be. But not sure where the problem is.

Remember, this issue occurs INFREQUENTLY on only one of the servers the cluster. Not sure whether an upgrade will help, as I didn't see any jira related to this.