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
9 years, 5 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, 9 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, 11 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
10 years, 1 month
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
10 years, 1 month
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
10 years, 1 month
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
10 years, 1 month
