[JBoss JIRA] (BAM-102) Class loading issue with custom events
by Gary Brown (JIRA)
Gary Brown created BAM-102:
------------------------------
Summary: Class loading issue with custom events
Key: BAM-102
URL: https://issues.jboss.org/browse/BAM-102
Project: Business Activity Monitoring
Issue Type: Task
Reporter: Gary Brown
Assignee: Gary Brown
Fix For: 1.0.0.M4
When custom event tests were in separate junit test classes, when running in jenkins they still seemed to be ran within the same server session - although all of the artifacts were undeployed and redeployed.
When the second test was run, the 'HandleCustomActivityEventProcessor' was not finding the events due to the 'instanceof' test failing - even though the events were CustomActivityEvents. So looks like some form of classloader issue, i.e. two different instances of the CustomActivityEvent class, both associated with different class loaders.
For now have moved both tests into the same junit class - originally they were separated to avoid impacting each other, as depending upon the order they were run, they had different effects. But have updated the test to overcome this ordering issue.
Need to construct some form of test showing the custom event epn being updated - not sure whether arquillian will support this, or whether it will just be a manual test.
--
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
12 years
[JBoss JIRA] (BAM-99) Visibility control on active collections
by Gary Brown (JIRA)
Gary Brown created BAM-99:
-----------------------------
Summary: Visibility control on active collections
Key: BAM-99
URL: https://issues.jboss.org/browse/BAM-99
Project: Business Activity Monitoring
Issue Type: Feature Request
Reporter: Gary Brown
Assignee: Gary Brown
Fix For: 1.0.0.M3
Enable user to configure the visibility of an active collection on the source. Support public (default) and private for now.
If private then any remote access to the collection should be prevented - so only allow other deployed apps to retrieve and access.
--
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
12 years
[JBoss JIRA] (BAM-96) Cache based active map
by Gary Brown (JIRA)
Gary Brown created BAM-96:
-----------------------------
Summary: Cache based active map
Key: BAM-96
URL: https://issues.jboss.org/browse/BAM-96
Project: Business Activity Monitoring
Issue Type: Feature Request
Reporter: Gary Brown
Assignee: Gary Brown
Enable an infinispan cache to be used as the underlying store for an active map.
Need to consider whether maintenance scripts etc should still be permitted?
The cleanup cycle may not be relevant, as the timestamps are created when an object is stored, but if stored on a different server, then the information would not be available - although it only really needs to be available on one server. However the underlying infinispan cache should have responsibility for these tasks.
--
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
12 years, 1 month
[JBoss JIRA] (BAM-77) Backing store for active collections
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/BAM-77?page=com.atlassian.jira.plugin.sys... ]
Gary Brown updated BAM-77:
--------------------------
Fix Version/s: 1.0.0.M4
(was: 1.0.0.M3)
> Backing store for active collections
> ------------------------------------
>
> Key: BAM-77
> URL: https://issues.jboss.org/browse/BAM-77
> Project: Business Activity Monitoring
> Issue Type: Feature Request
> Reporter: Gary Brown
> Assignee: Gary Brown
> Fix For: 1.0.0.M4
>
>
> Although active collections generally represent a realtime transient snapshot of some relevant information, on occasions it may be necessary that all instances of a collection across a cluster are consistent, and complete (e.g. on a server startup situation).
> In this situations, the active collection would require some shared state mechanism (e.g. cache) to replicate their state. The issue is that each server in the cluster will attempt to update their instance of the collection, so this needs to be handled (e.g. before applying the change check that it is required - but this may require some synchronization).
> Due to the potential performance implications, this type of active collection should ideally only be used where infrequent updates are applied.
--
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
12 years, 1 month