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
                        
                        
                 
         
 
        
            
        
        
        
                
                        
                        
                                
                                
                                        
                                                
                                        
                                        
                                        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, 2 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
                        
                        
                 
         
 
        
            
        
        
        
            
        
        
        
            
        
        
        
                
                        
                                
                                
                                        
                                
                         
                        
                                
                                
                                        
                                                
                                        
                                        
                                        Project Jigsaw: The module system was integrated into JDK 9 and is now available for testing in early-access, build 111.
                                
                                
                                
                                    
                                        by Rory O'Donnell
                                    
                                
                                
                                        
Hi Galder,
Project Jigsaw <http://openjdk.java.net/projects/jigsaw/> is an enormous 
effort, encompassing six JEPs 
<http://openjdk.java.net/projects/jigsaw/#jeps> implemented by dozens of 
engineers over many years.
So far we’ve defined a modular structure for the JDK (JEP 200 
<http://openjdk.java.net/jeps/200>), reorganized the source code 
according to that structure
(JEP 201 <http://openjdk.java.net/jeps/201>), and restructured the JDK 
and JRE run-time images to support modules (JEP 220 
<http://openjdk.java.net/jeps/220>). The last major component,
the module system itself (JSR 376 
<http://openjdk.java.net/projects/jigsaw/spec/> and JEP 261 
<http://openjdk.java.net/jeps/261>), was integrated into JDK 9 earlier 
this week and is now available for testing
in early-access build 111 - here. <http://jdk9.java.net/download>
More information on Mark Reinhold's blog [1]
Rgds, Rory
Project Jigsaw <http://openjdk.java.net/projects/jigsaw/> is an enormous 
effort, encompassing six JEPs 
<http://openjdk.java.net/projects/jigsaw/#jeps> implemented by dozens of 
engineers over many years. So far we’ve defined a modular structure for 
the JDK (JEP 200 <http://openjdk.java.net/jeps/200>), reorganized the 
source code according to that structure (JEP 201 
<http://openjdk.java.net/jeps/201>), and restructured the JDK and JRE 
run-time images to support modules (JEP 220 
<http://openjdk.java.net/jeps/220>). The last major component, the 
module system itself (JSR 376 
<http://openjdk.java.net/projects/jigsaw/spec/> and JEP 261 
<http://openjdk.java.net/jeps/261>), was integrated into JDK 9 
<http://openjdk.java.net/projects/jdk9> earlier this week and is now 
available for testing in early-access build 111 
<http://jdk9.java.net/download>.
[1] http://mreinhold.org/blog/jigsaw-module-system
Project Jigsaw <http://openjdk.java.net/projects/jigsaw/> is an enormous 
effort, encompassing six JEPs 
<http://openjdk.java.net/projects/jigsaw/#jeps> implemented by dozens of 
engineers over many years. So far we’ve defined a modular structure for 
the JDK (JEP 200 <http://openjdk.java.net/jeps/200>), reorganized the 
source code according to that structure (JEP 201 
<http://openjdk.java.net/jeps/201>), and restructured the JDK and JRE 
run-time images to support modules (JEP 220 
<http://openjdk.java.net/jeps/220>). The last major component, the 
module system itself (JSR 376 
<http://openjdk.java.net/projects/jigsaw/spec/> and JEP 261 
<http://openjdk.java.net/jeps/261>), was integrated into JDK 9 
<http://openjdk.java.net/projects/jdk9> earlier this week and is now 
available for testing in early-access build 111 
<http://jdk9.java.net/download>.
Project Jigsaw <http://openjdk.java.net/projects/jigsaw/> is an enormous 
effort, encompassing six JEPs 
<http://openjdk.java.net/projects/jigsaw/#jeps> implemented by dozens of 
engineers over many years. So far we’ve defined a modular structure for 
the JDK (JEP 200 <http://openjdk.java.net/jeps/200>), reorganized the 
source code according to that structure (JEP 201 
<http://openjdk.java.net/jeps/201>), and restructured the JDK and JRE 
run-time images to support modules (JEP 220 
<http://openjdk.java.net/jeps/220>). The last major component, the 
module system itself (JSR 376 
<http://openjdk.java.net/projects/jigsaw/spec/> and JEP 261 
<http://openjdk.java.net/jeps/261>), was integrated into JDK 9 
<http://openjdk.java.net/projects/jdk9> earlier this week and is now 
available for testing in early-access build 111 
<http://jdk9.java.net/download>.
-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin,Ireland
                                
                         
                        
                                
                                9 years, 7 months
                        
                        
                 
         
 
        
            
        
        
        
            
        
        
        
                
                        
                        
                                
                                
                                        
                                                
                                        
                                        
                                        PSA: CI test failure links are not permalinks
                                
                                
                                
                                    
                                        by Dan Berindei
                                    
                                
                                
                                        Hi guys
It's a good idea to link to CI test failures in JIRA, as the build
logs can sometimes shed more information. However, those links will be
dead after a few months, so please don't rely on them exclusively.
Cheers
Dan
                                
                         
                        
                                
                                9 years, 7 months
                        
                        
                 
         
 
        
            
        
        
        
                
                        
                                
                                
                                        
                                
                         
                        
                                
                                
                                        
                                                
                                        
                                        
                                        Re: [infinispan-dev] Distributed Counter Discussion
                                
                                
                                
                                    
                                        by Eric Wittmann
                                    
                                
                                
                                        Greetings.  Apologies for coming in a bit late on this conversation. 
Tristan pointed me to it a couple of days ago and unfortunately I'm just 
now getting time to reply.
I can try to quickly give an overview of apiman's (JBoss API Management 
Gateway) requirements.
What we're trying to do is implement support for Limiting policies:
* Rate Limiting/Throttling (e.g. limit of 100 requests per second)
* Quotas (e.g. limit of 100,000,000 requests per month)
* Transfer Quotas (e.g. limit of 2.5GB of data downloaded per day)
We will need to support multiple backing implementations of the Rate 
Limiter, and we're trying to get Infinispan to be one of those 
implementations.
In no particular order, we would need the following characteristics:
- Can be "squishy" for quotas and transfer quotas:  If you
   get 100,001,017 requests that's OK
- Strict would be cool as an option:  Hard-fail when the
   counter reaches the limit - no chance it will go over.
- Lots of individual counters:  users may publish 100s of
   APIs to the Gateway, and each API may be consumed by
   100s or 1000s of users/client.  Depending on configuration
   of the policy, *each* user/client has a separate limit.
- Counters need to be created dynamically:  users can
   add APIs via the Management UI, configure them to add
   policies (e.g. a Quota policy) and then publish them to
   a running Gateway, at which point end users can invoke
   the API through the Gateway, which will use a counter
   to enforce the Quota.
- Counter values reset at the end of a time boundary:  for
   example, at the end of the month the counter value for
   the example quota above would reset to 0.
- Don't care (right now) what the counter value is: at the
   moment we simply need to know if some counter max value
   has been reached.  In the future we would like to know
   when a max value is being "approached" (e.g. to notify a
   user)
- Should be persistent: it would not be ideal for e.g. per-
   month quota values to be lost on server restart.
That's all the high level requirements I can think of off the top of my 
head, and after reading all of the current messages in this thread. :)
-Eric
                                
                         
                        
                                
                                9 years, 7 months
                        
                        
                 
         
 
        
            
        
        
        
                
                        
                        
                                
                                
                                        
                                                
                                        
                                        
                                        Google load balancer design
                                
                                
                                
                                    
                                        by Emmanuel Bernard
                                    
                                
                                
                                        http://blog.acolyer.org/2016/03/21/maglev-a-fast-and-reliable-software-ne...
Interesting read. Some data points I extracted. 
350 ns per parquet. Ensuring a 300us during load. 
Some math I was not aware of:
[quote]
--
Let N be the size of a VIP’s backend pool. A table is constructed with M entries, where M is a prime number and M > 100 * N, which will ensure at most a 1% difference in hash space assigned to backends.
--
Might be interesting in our virtual nodes logic. The segment size might not be too friendly here though. 
They do use try to ensure relative stability of the targeted backend for a given key even when the pool of backend changes (e.g. one server down)
Emmanuel 
                                
                         
                        
                                
                                9 years, 7 months