Pleaseee add the maven-compiler-plugin

[krishna81m]

Was trying to break my head why Eclipse (soon EOL with IntelliJ) kept complaining even when I noticed that properties set.

        <maven-compiler-plugin.source.version>1.7</maven-compiler-plugin.source.version>
        <maven-compiler-plugin.target.version>1.7</maven-compiler-plugin.target.version>

Only to find hours later that the plugin itself was missing.

                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>2.3.2</version>
                <configuration>
                    <source>${maven-compiler-plugin.source.version}</source>
                    <target>${maven-compiler-plugin.target.version}</target>
                </configuration>
            </plugin>

[fridgebuzz]

This problem is specific to Eclipse (which I don't use so I never noticed.) The least intrusive solution would be to add:

        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.1</version>
            <configuration>
                <source>${maven-compiler-plugin.source.version}</source>
                <target>${maven-compiler-plugin.target.version}</target>
            </configuration>
        </plugin>

[krishna81m]

Oops that is what I added in my comment above:), it was lost due to improper markup, sorry.

[krishna81m]

Testing this library to force different JVM threads to go into wait state by acquiring read locks while only one thread acquires a write lock to write to cache. All of them start by attempting to acquire a write lock using lock.writeLock().tryLock(5 * LONG_DELAY_MS, TimeUnit.MILLISECONDS) but only one succeeds. Is there an option to acquire writeLock and return quickly if lock is acquired and return quickly if lock is already acquired by another thread without specifying any delay?
The remaining threads will remain waiting on a read lock until the write lock thread unlocks.

[ThoughtWire]

If you mean is tryLock() supported (no timeout version), the answer is no.
Because distributed data structures are used there is no way to obtain an
immediate response on the lock's availability. I'm not sure what you're
trying to achieve, maybe you can post a code snippet. Sounds like maybe you
could use a distributed semaphore or something, rather than doing a fancy
dance with the read/write lock...

On Wed, Apr 22, 2015 at 4:33 PM, krishna81m [email protected]
wrote:

Testing this library to force different JVM threads to go into wait state
by acquiring read locks while only one thread acquires a write lock to
write to cache. All of them start by attempting to acquire a write lock
using lock.writeLock().tryLock(5 * LONG_DELAY_MS, TimeUnit.MILLISECONDS)
but only one succeeds. Is there an option to acquire writeLock and return
quickly if lock is acquired and return quickly if lock is already acquired
by another thread without specifying any delay?
The remaining threads will remain waiting on a read lock until the write
lock thread unlocks.

—
Reply to this email directly or view it on GitHub
#7 (comment)
.

[krishna81m]

There are a bunch of threads in "different JVMs" trying to do the same operation and cache the result for other threads. We are trying to make threads wait until a specific single thread makes the cache entry. Although cache operations themselves are Atomic, the calculation is expensive! If locking is fairly cheaper and faster, the smaller time to acquire lock will compensate for many expensive operations by other threads as one thread should suffice to do the job.

[fridgebuzz]

Off the top of my head (sorry, not much time to think about this), it sounds like something that an ICondition would be useful for. All threads acquire a lock and then wait on a particular condition. One thread should succeed right away and the others will awake when condition.signalAll() is called by the first thread. You'll have to be careful with what happens once those threads have been woken up, but that's well-known sort of stuff wrt Object.wait() and notifyAll().

[krishna81m]

Hmm, how different is this from reentrant writeLock() and readLock() wait pattern? I completed development and started testing following changes:

do some work in Future that takes at least X ms where X > 10 ms is known
ReadWriteLock lock = lockService.getReentrantReadWriteLock(KEY);

TRY and acquire write lock within X ms
WL = rwLock.writeLock().tryLock(X, MILLISECONDS);

if (WL) {
 Work and Put In Cache If Absent and release WL
}
else {
  RL = rwLock.readLock().tryLock(X, MILLISECONDS);
  if(RL){
    acquire read lock and wait to read from same cache
    if (not found){
       Work and Put In Cache If Absent, if present use the same from cache
    } 
  }
  else {
    Work and Put In Cache If Absent, if present use the same from cache
  }
}

[krishna81m]

Noticed that write locks are not satisfying the lock wait time, when I chose a 20 ms time out, I can see at least 100-200 ms which is not good. What I noticed was that while most of them were under 20, there were quite a bit taking very large times. Some taking almost 10s :(

long startTs = System.currentTimeMillis();  
rwLock.writeLock().tryLock(20, TimeUnit.MILLISECONDS);
(System.currentTimeMillis() - startTs));

Here is a histogram of a small sample:
Found 76369 records distributed in 1469 distinct values between 2 and 18392

< 100.00 70034 91.70 (hidden to show how values only above 100ms)
100.00 4954 98.19 ____________________________________________________________________________________________________
473.31 608 98.99 _____________
846.61 102 99.12 ___
1219.92 9 99.13 _
1593.22 9 99.14 _
1966.53 12 99.16 _
2339.84 11 99.18 _
2713.14 11 99.19 _
3086.45 13 99.21 _
3459.76 5 99.21 _
3833.06 13 99.23 _
4206.37 32 99.27 _
4579.67 62 99.35 __
4952.98 59 99.43 __
5326.29 35 99.48 _
5699.59 48 99.54 _
6072.90 23 99.57 _
6446.20 11 99.58 _
6819.51 10 99.60 _
7192.82 9 99.61 _
7566.12 6 99.62 _
7939.43 6 99.62 _
8312.73 2 99.63 _
8686.04 5 99.63 _
9059.35 17 99.66 _
9432.65 26 99.69 _
9805.96 43 99.75 _
10179.27 44 99.80 _
10552.57 27 99.84 _
10925.88 27 99.87 _
11299.18 50 99.94 __
11672.49 16 99.96 _
12045.80 3 99.96 _
17272.08 1 99.97 _
17645.39 20 99.99 _
18018.69 5 100.00 _
18392.00 1 100.00 _