Category Archives: jboss / wildfly

Using Infinispan for high availability, extreme performance, Manik Surtani & Galder Zamarreño

JBoss World Boston notes, Using Infinispan for high availability, extreme performance, Manik Surtani & Galder Zamarreño

Infinispan as…
in memory object cache
… clustering/high availability toolkit
… clustered in-memory cache
… in-memory data grid
… cloud ready data store

Local, in-memory object cache
– performance booster
– good when data is hard to calculate, expensive to retrieve or frequently accessed

Better than hashmap
– better concurrency
– built-in eviction
– overflow to disk
– warm start, preloading
– events, notifications
– highly configurable locking strategies
– JTA compatible
– JMX monitoring

Tips and tricks
– use eviction, low-cost boudnedd container, recency based: LIRS
– tune for read-heavy, use lock-striping, READ_COMMITTED is often sufficient
– pre-loading can be expensive

Clustering toolkit
– High availability
– fail-over
– scale-out
– uses self-discovery, self-healing

Tips and tricks
– strive for session affinity, very valid optimization, will allow fo async communication
– replicated mode vs distribution? Depend on cluster size
– distribution: co-locate related state
– pre-loading, state transfer not necessary, use a ClusterCacheLoader

Clustered in-memory cache
– performance booster
– similar to local cache
– cluster-aware
– more shared-cache space

Writing data in cache, use putForeExternalRead() vs put()
– update cache state vs update “real” state
– fail-fast instead of lock
– fail quietly instead of throw exception
– does not affect transaction

Tips and tricks
– same as local cache
– putForExternalRead() API
– use invalidation clustered mode
— very efficient: only keys on the wire
— async communication helps even more
– replication can be used
— if cluster is small and data cached is small
— overall data volume can be contained in a single node

In-memory data grid
– multiple access mechanisms
– embedded: P2P
– client/server: REST, memcached, HotRod
– familiar APIs
— cache API
— upcoming JPA-like API
– Queryability

FADE: Fast, Available, Distributed, Elactic

Tips and tricks
– session affinity is nice to have
– async communication and eventual consistency
– use distributed mode, replicated will work to a limit
– tune performance vs durability, numOwners
– dedicated data tier helps you build stateless, elastic application tier
– HotRod: most efficient endpoint

Cloud-ready data store
– RDBMS in inelastic, single point of failure
– data grid deals with transience, is elastic, scalable, distributed
– API is key

Tips and tricks
– asme as data grids
– REST: use load balancer
– use a transport that does not use multicast (not supported on something like EC2)

JBoss BPM Past, Present & Future, John Graham

JBoss World Boston notes, JBoss BPM Past, Present & Future, John Graham

Past :

– based on jPDL
– deployments : stand-alone, SOA-Platform, Seam
– jBPM 3, exising, stable
– jBPM 4, improved system, community effort

– business rules
– BPM in drools flow

– WS-BPEL 2.0
– based on Apache ODE
– release 2.1
– integration with SOA

– WS-CDL : choreography description language
– Pi calculus
– testable architecture, development validation, execution governance
– BPMN 2 work in progress

Present :

– Perspectives : rules-based, process-based, SOA-driven
– Need to integrate
– Need to avoid overlap
– Enable emergent usage
– Where to go?

jBPM 4 and drools flow are integrating and will be jBPM 5 which should be available in 2011

Key characteristics
– Business process engine
— BPMN2 native execution
— lightweight, embeddable
— generic process engine
– Full life cycle support
– Higher-level, domain-specific processes
– Powerful business rules and vent processing integration

BPMN 2.0
– OMG standard
— graphical notation
— process definition format
— execution semantics
– extensible
– interoperability

Generic process engine
– persistence
– transactions
– times
– expression dialects
– multi-threading
– events
– commands + interceptors
– session management

Future :

jBPM roadmap
– currently under community review
– more details soon
– 5.0 focus now on core components, should be ready by the end of the year
– regular (2-3 month) releases after that

Adaptive processes
– ability to handle change, complexity, …

– Externalise logic as rules

Zen of class loading, Jason Green

JBossWorld Boston, Jason T Greene, Zen of class loading

What is the Class class
– represents a class
– allocates memory on heap and permgen
– is referenced by every object instance of that class
– Unique (by name) only to a ClassLoader
– holds a reference to the ClassLoader

What is a ClassLoader
– responsible for loading classes
– holds strong reference to all classes it loads
– optional parent for delegation

Problem #1 – OutOfMemory:PermGen
– too many classes loaded
– sizing could be wrong, big application with many classes
– possible classloader leak
— hot deployment causes new classloader
— one instance to an object prevents garbage collection of all classes loaded by the classloader

Common leak sources
– static field on a class with a long lifecycle (on another classloader)
– caching frameworks
– persistent thread locals (automatic cleaning is *very* important)
– framework bugs (logging frameworks, third-party frameworks)

JDK class loading delegation
– parent-first prevents overriding a parent
– custom classloaders can do this (and they do!)
– bootstrap is searched even if parent==null
– bootstrap classes often return null for getClassLoader()

JDK has default hierarchy
– boot classpath (including lib/endorsed)
– application/system loader (defined class path)
– user loader

Problem #2 – ClassNotFoundException
– classes are not visible to the loader
– unintentional ref/dep
– solution: audit cross jar references (Tattletale)

EE class loading model
– child-first allows deployments to override parent classes and jars
— support bundling a diffrent version of a framework than in the ear
– EJB jars share classes with the EAR
– WARs do not share classes, but do see classes in the EAR
– RARs and global EJB-Jars visible to everyone

Problem #3 – ClassCastException on the same name
– duplicate class in isolated loaders
– usually a packaging problem
– common scenario – bundling ejb local interfaces in a WAR

Domain based models (default class loader)
– hot deploy requires classloader per deployment
– normal classloader isolations disallows pass-by-reference
– domains allow class sharing between class loaders
– duplicate classes are resolved using fist-come-first-server
– allows big ball-of-mud
– shared class cache
– default : one domain (defaultDomain) for all, plus one for each WAR
– fix : isolate ears in deployers/ear.deployer

Evolution to module class loaders
– applications don’t always fit hierarchical models
– declare specific dependencies, each jar is a module
— each jar declares dependencies on a name and version
– module system responsible for mapping to class loader (delegation map)
– module has imports and exports

OSGi bundle = module mentioned here, require-bundle, import-package, export-package

AS5 support package and module import/export, jboss-classloading.xml (import=requirements, export-capabilities)
domain style model is also possible

future :
– JDK7 is probably going modular (project jigsaw – JSR-294)
– EE7 will probably follow
– AS7 will be modular

Tattletale can produce module descriptors using a plug-in