Spring module - change dependencies to Uber Jars
                                
                                
                                
                                    
                                        by Sebastian Laskawiec
                                    
                                
                                
                                        Hey!
I'm currently trying to solve a tricky class loading issue connected to
Spring, CDI and Uber Jars. Here's the scenario:
   - Remote Uber Jar contains CDI module
   - Our Hot Rod client use newer version of JBoss Logging which is present
   in Wildfly/EAP modules
   - However EAP and Wildfly will load (and make available for deployment)
   their own version of JBoss Logging [1]
      - The easiest fix for this is to relocate JBoss Logging package in
      Uber Jar
   - Spring module requires some classes from Infinispan Common and they in
   turn need BasicLogger from JBoss Logging
      - If we relocate JBoss Logging and will try to use Uber Jar with
      Spring - we will end up with classloading issue [2]
So it seems the best approach is to make Spring depend on Uber Jars instead
of "small ones". Of course, users who use small jars will probably be
affected by this change (they would have to either accept using Uber Jars
or exclude them in their poms and add dependencies manually).
Is anyone against this solution? JIRA tracking ticket: [3].
Thanks
Sebastian
[1] Scenario with Weld enabled WAR
https://docs.jboss.org/author/display/AS7/Implicit+module+dependencies+fo...
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1266831#c7
[3] https://issues.jboss.org/browse/ISPN-6132
                                
                         
                        
                                
                                8 years, 11 months
                        
                        
                 
         
 
        
            
        
        
        
                
                        
                        
                                
                                
                                        
                                                
                                        
                                        
                                        Multi tenancy support for Infinispan
                                
                                
                                
                                    
                                        by Sebastian Laskawiec
                                    
                                
                                
                                        Dear Community,
Please have a look at the design of Multi tenancy support for Infinispan
[1]. I would be more than happy to get some feedback from you.
Highlights:
   - The implementation will be based on a Router (which will be built
   based on Netty)
   - Multiple Hot Rod and REST servers will be attached to the router which
   in turn will be attached to the endpoint
   - The router will operate on a binary protocol when using Hot Rod
   clients and path-based routing when using REST
   - Memcached will be out of scope
   - The router will support SSL+SNI
Thanks
Sebastian
[1]
https://github.com/infinispan/infinispan/wiki/Multi-tenancy-for-Hotrod-Se...
                                
                         
                        
                                
                                9 years, 1 month
                        
                        
                 
         
 
        
            
        
        
        
                
                        
                        
                                
                                
                                        
                                                
                                        
                                        
                                        jdk8backported package
                                
                                
                                
                                    
                                        by Radim Vansa
                                    
                                
                                
                                        Hi,
although we're on Java 8, there's still the package 
org.infinispan.*.jdk8backported in our codebase. Is there any plan (and 
possibility) to remove these and use implementation provided by runtime? 
Or have we tweaked them too much, so shall we rather rename them?
Radim
-- 
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
                                
                         
                        
                                
                                9 years, 3 months
                        
                        
                 
         
 
        
            
        
        
        
                
                        
                                
                                
                                        
                                
                         
                        
                                
                                
                                        
                                                
                                        
                                        
                                        Distributed Counter Discussion
                                
                                
                                
                                    
                                        by Pedro Ruivo
                                    
                                
                                
                                        Hi everybody,
Discussion about distributed counters.
== Public API ==
interface Counter
String getName() //counter name
long get()	 //current value. may return stale value due to concurrent 
operations to other nodes.
void increment() //async or sync increment. default add(1)
void decrement() //async or sync decrement. default add(-1)
void add(long)   //async or sync add.
void reset()     //resets to initial value
Note: Tried to make the interface as simple as possible with support for 
sync and async operations. To avoid any confusion, I consider an async 
operation as happening somewhat in the future, i.e. eventually 
increments/decrements.
The sync operation happens somewhat during the method execution.
interface AtomiCounter extends Counter
long addAndGet()       //adds a returns the new value. sync operation
long incrementAndGet() //increments and returns the new value. sync 
operation. default addAndGet(1)
long decrementAndGet() //decrements and returns the new value. sync 
operation. default addAndGet(-1)
interface AdvancedCounter extends Counter
long getMin/MaxThreshold() //returns the min and max threshold value
void add/removeListener()  //adds a listener that is invoked when the 
value change. Can be extended to notify when it is "reseted" and when 
the threshold is reached.
Note: should this interface be splitted?
== Details ==
This is what I have in mind. Two counter managers: one based on JGroups 
counter and another one based on Infinispan cache.
The first one creates AtomicCounters and it first perfectly. All 
counters are created with an initial value (zero by default)
The second generates counters with all the options available. It can mix 
sync/async operation and all counters will be in the same cache. The 
cache will be configure by us and it would be an internal cache. This 
will use all the features available in the cache.
Configuration-wise, I'm thinking about 2 parameters: number of backups 
and timeout (for sync operations).
So, comment bellow and let me know alternatives, improvement or if I 
missed something.
ps. I also consider implement a counter based on JGroups-raft but I 
believe it is an overkill.
ps2. sorry for the long email :( I tried to be shorter as possible.
Cheers,
Pedro
                                
                         
                        
                                
                                9 years, 5 months
                        
                        
                 
         
 
        
            
        
        
        
                
                        
                                
                                
                                        
                                
                         
                        
                                
                                
                                        
                                                
                                        
                                        
                                        Early Access builds of JDK 9 b116 & JDK 9 with Project Jigsaw b115 (#4909) are available on java.net
                                
                                
                                
                                    
                                        by Rory O'Donnell
                                    
                                
                                
                                        
Hi Galder,
Early Access b116 <https://jdk9.java.net/download/> for JDK 9 is 
available on java.net, summary of  changes are listed here 
<http://download.java.net/java/jdk9/changes/jdk-9+116.html>.
Early Access b115 <https://jdk9.java.net/jigsaw/> (#4909) for JDK 9 with 
Project Jigsaw is available on java.net.
Recent changes:
  * in b114
      o Replace
        –com.apple.eawt
        –com.apple.eio
        With platform independent alternatives in java.awt
  * in b115
      o As per JEP 260, all non-Critical types/members should be moved
        out of
        sun/reflect and placed into a non-exported package. Only
        critical APIs
        should remain in sun.reflect.
We are very interested in hearing your experiences in testing any Early 
Access builds. Have you have begun testing against
JDK 9 and or JDK 9 with Project Jigsaw EA builds, have you uncovered 
showstopper issues that you would like to discuss?
We would really like to hear your findings so far, either reply to me or 
via the mailing lists [1], [2].
Rgds,Rory
[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/
[2] http://mail.openjdk.java.net/pipermail/jdk9-dev/
-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin,Ireland
                                
                         
                        
                                
                                9 years, 6 months
                        
                        
                 
         
 
        
            
        
        
        
            
        
        
        
            
        
        
        
                
                        
                        
                                
                                
                                        
                                                
                                        
                                        
                                        Marshalling/unmarshalling known type
                                
                                
                                
                                    
                                        by Radim Vansa
                                    
                                
                                
                                        Hi,
I've noticed that sometimes we marshall objects just using 
output.writeObject() even though we know the target type - one example 
for all is CommandInvocationId. That's somewhat suboptimal, as we know 
that there won't be any CommandInvocationIdEx, so we could spare the 
externalizer lookup and few bytes for object identifier.
Is there any better way than
new CommandInvocationId.Externalizer().writeObject(output, 
commandInvocationId)?
Should we use this ^? I guess that object allocation will be eliminated 
here easily.
Radim
-- 
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
                                
                         
                        
                                
                                9 years, 6 months
                        
                        
                 
         
 
        
            
        
        
        
                
                        
                                
                                
                                        
                                
                         
                        
                                
                                
                                        
                                                
                                        
                                        
                                        Status 2016/04/25
                                
                                
                                
                                    
                                        by Sebastian Laskawiec
                                    
                                
                                
                                        Hey!
Unfortunately I won't be able to make it for today's IRC meeting (if there
will be one), so here is my status:
   - ISPN-5721 SNI implementation is done (2 PRs sent [1][2]). Both PRs are
   waiting for review.
   - I'm planning to write some blog post as soon as they are merged.
   - This week I'll concentrate on setting up Openshift environment on my
   local laptop and investigating the best way to implement:
      - a Hotrod server image.
         - At the moment the best way is to create a new example and ask
         Openshift team to put it under their Github organization [3].
This way it
         will be tested by their testsuite (!!!).
         - Cloud Enablement team also plans to do some work with this area
         but I couldn't get any meaningful information.
         - The first iteration of the image might be really quick and dirty
         (just to start moving forward with other things)
      - investigating Config Map [4] and how this might help with Hotrod
      server configuration.
      - accessing the data from different pods (Hotrod cluster is in Pod A
      and clients are in Pod B)
      - think a little bit about multi tenancy (a quick and dirty solution
      would be to prefix caches with cache containers but maybe there
is a better
      way)
   - Plus, as usual, some small bug fixes, CI maintenance and product
   related work.
That's all from me.
Thanks!
Sebastian
[1] https://github.com/infinispan/infinispan/pull/4262
[2] https://github.com/infinispan/infinispan/pull/4255
[3] https://github.com/search?q=org%3Aopenshift+-ex
[4] https://docs.openshift.org/latest/dev_guide/configmaps.html
                                
                         
                        
                                
                                9 years, 6 months