HWKAPM-478 Support caching information in a clustered environment #444
Conversation
|
Review notes - this PR contains some minor changes relates to serialization of some events to deal with null strings. The main change is how cached data (Producer Information and Communication Details) is stored. The initial implementation assumed when clustering the servers a distributed cache would be used - however due to problems getting the distributed cache working lead me to rethink this approach - as the data being cached is distributed via JMS anyway, rather than redistribute it again via infinispan, it seemed better to leverage local caches (to help with memory management) that are initialised via the JMS published data. There are some potential issues, discussed in https://issues.jboss.org/browse/HWKAPM-479, which may mean a distributed cache will eventually be used, but while the main focus is on monitoring short lived transaction/trace instances, this seems like a viable solution. So the main changes are to introduce some non-durable subscribing topic MDBs to receive the data and store it in the local caches. |
| /** | ||
| * @author gbrown | ||
| */ | ||
| public class SerializationUtil { |
There was a problem hiding this comment.
Have you looked into using some other serialization library instead? I recall that the default from the jdk is rather slow and clumsy.
I don't mean that you need to change it now
There was a problem hiding this comment.
No haven't looked into any others yet, but if can look at others if the performance in this area becomes an issue. Currently the serialization is only used with the caching.
|
I think it certainly makes sense to pick the data from the Topic, if it is sent there anyway, to update all local caches. |
This is also disturbing as we're depending on ispan caches in a couple of other places. Can you elaborate? |
|
I had two wildfly 10 servers running in a cluster, with a distributed cache defined in the standalone-ha.xml. Logs showed the cluster was being established, but for some reason no data was being shared between the nodes. Its most likely I got some config wrong, but once I thought about the current solution (based on JMS), I didn't investigate further. |
|
@pilhuhn Added the extra test, and changed MDBs so now use durable topic subscription based on a clientId associated with the 'jboss.node.name'. |
objectiser
force-pushed
the
HWKAPM-478
branch
2 times, most recently
from
d974c25
to
4739562
Compare
|
@pilhuhn ok to merge? |
No description provided.