Version of paranamer library used by lift-json is not thread-safe, can it be upgraded?

[Benno Kittelmann]

Hi all,

We had an issue yesterday in one of our applications that makes heavy use of the lift-json package, version 2.6.2. The application is multi-threaded. One thread that attempted to deserialize JSON data was stuck busy waiting, and all other threads doing any kind of JSON de/serialization were blocked because of that stuck thread.

Relevant excerpt from a thread dump that shows the still running, but not progressing thread:

java.lang.Thread.State: RUNNABLE
    at java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:408)
    - locked <0x00000007e55a8340> (a java.lang.ref.ReferenceQueue)
    at java.util.WeakHashMap.getTable(WeakHashMap.java:417)
    at java.util.WeakHashMap.get(WeakHashMap.java:464)
    at com.thoughtworks.paranamer.CachingParanamer.lookupParameterNames(CachingParanamer.java:72)
    at com.thoughtworks.paranamer.CachingParanamer.lookupParameterNames(CachingParanamer.java:68)
    at net.liftweb.json.Meta$ParanamerReader$.lookupParameterNames(Meta.scala:89)
    at net.liftweb.json.Meta$Reflection$.argsInfo$1(Meta.scala:237)
    at net.liftweb.json.Meta$Reflection$.constructorArgs(Meta.scala:257)

Here's an example of one of the threads which were blocking:

java.lang.Thread.State: BLOCKED (on object monitor)
    at java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:386)
    - waiting to lock <0x00000007e55a8340> (a java.lang.ref.ReferenceQueue)
    at java.util.WeakHashMap.getTable(WeakHashMap.java:417)
    at java.util.WeakHashMap.get(WeakHashMap.java:464)
    at com.thoughtworks.paranamer.CachingParanamer.lookupParameterNames(CachingParanamer.java:72)
    at com.thoughtworks.paranamer.CachingParanamer.lookupParameterNames(CachingParanamer.java:68)
    at net.liftweb.json.Meta$ParanamerReader$.lookupParameterNames(Meta.scala:89)
    at net.liftweb.json.Meta$Reflection$.argsInfo$1(Meta.scala:237)
    at net.liftweb.json.Meta$Reflection$.constructorArgs(Meta.scala:253)

As you see, it's not really a fault of lift-json but rather a problem with the Paranamer library. Looks like a known issue(https://github.com/paul-hammant/paranamer/issues/8) and purportedly solved in Paranamer 2.6.1

Would it be possible to update lift-json to use a more recent Paranamer library with a version > 2.6.1?

Else we'd have to consider excluding this transitive dependency and supply it separately in our build.

I can provide more details if required.

Thanks and best regards
Benno

[Andreas Joseph Krogh]

We use paranamer 2.7.1 with lift-json and it works. Just update your local deps.

 

--

Andreas Joseph Krogh

CTO / Partner - Visena AS

Mobile: +47 909 56 963

and...@visena.com

www.visena.com

 

[Benno Kittelmann]

Yep, that's what we've tested in our build too and are probably going to do in the short term. The purpose of my post is to raise attention to this issue to the maintainers of lift-json, and to get the dependency upgraded. No need for everybody to run into this issue and update local dependencies when it can be fixed upstream. :)

Best regards
Benno

[Antonio Salazar Cardozo]

So combined with https://groups.google.com/d/msg/liftweb/RoZbMT7Pp3Q/HtHkciWb94sJ I guess

this makes two issues with paranamer pre-2.7.1? Andreas, you said 2.7.1 is only available in

SNAPSHOT form at the moment, right?

Thanks,

Antonio

[Andreas Joseph Krogh]

På fredag 03. juli 2015 kl. 18:21:37, skrev Antonio Salazar Cardozo <savedf...@gmail.com>:

So combined with https://groups.google.com/d/msg/liftweb/RoZbMT7Pp3Q/HtHkciWb94sJ I guess

this makes two issues with paranamer pre-2.7.1? Andreas, you said 2.7.1 is only available in

SNAPSHOT form at the moment, right?

 

Correct. There's an issue asking for it to be published: https://github.com/paul-hammant/paranamer/issues/22

 

What we've done is to build it and deployed it to our local Nexus-repo.

[Antonio Salazar Cardozo]

Cool. Let's keep an eye on it and definitely bump Lift 3 once 2.7.1 final is out, and then

decide what to do about 2.6 given that we're talking about something that will break for

Java 8 in addition to the problem in this thread.

Thanks,

Antonio

[Andreas Joseph Krogh]

På lørdag 04. juli 2015 kl. 00:47:06, skrev Antonio Salazar Cardozo <savedf...@gmail.com>:

Cool. Let's keep an eye on it and definitely bump Lift 3 once 2.7.1 final is out, and then

decide what to do about 2.6 given that we're talking about something that will break for

Java 8 in addition to the problem in this thread.

Thanks,

Antonio

 

Yes

[Benno Kittelmann]

On Friday, July 3, 2015 at 6:21:37 PM UTC+2, Antonio Salazar Cardozo wrote:

So combined with https://groups.google.com/d/msg/liftweb/RoZbMT7Pp3Q/HtHkciWb94sJ I guess

this makes two issues with paranamer pre-2.7.1?

No: The issue I was starting this thread about is fixed in paranamer 2.6.1. At least that's what https://github.com/paul-hammant/paranamer/issues/8 suggests.

Best regards
Benno

[Andreas Joseph Krogh]

I think what Antonio meant was that paranamer pre-2.7.1 (as in versions before 2.7.1) has two issues which affects Lift

1. Thread-safety, issue 8

2. Failing to process java8 bytecode containing lambda-expressions, issue 17

 

So, when 2.7.1 is released, containing fixes for both issues, and hits Maven central, we're good.

[Matt Farmer]

FYI. If this is important enough I could publish a build under my own version code signed using my key to bintray. That would get us the latest behavior and allow us to distribute it (since it would be resolvable via bintray).

I've done that before with some libraries that are slow to publish. Or we could all email the maintainer directly. That's also effective. ;)

—
Matt Farmer | Blog | Twitter

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Antonio Salazar Cardozo]

Oh nice, thanks for the offer :) I think for other code that's fine, but for Lift to publish with a non-official

build as a dependency would be very bad. I'd rather give the paranamer folks a chance to publish to

maven central before getting too crazy—in the meantime, it seems like everyone has a solution they

can use right now by replacing the dependency in their builds.

(Though would someone perhaps be willing to post an example of what that looks like for other folks

to reference?)

Thanks,

Antonio

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.