[JAVA-2692] NullPointerException logged when compression is enabled Created: 06/Dec/17 Updated: 28/Oct/23 Resolved: 11/Dec/17 |
|
| Status: | Closed |
| Project: | Java Driver |
| Component/s: | Internal |
| Affects Version/s: | 3.6.0 |
| Fix Version/s: | 3.6.1 |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Scott Lipcon | Assignee: | Jeffrey Yemin |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
MacOS, server 3.6.0, java-driver 3.6.0 |
||
| Description |
|
When I enable client side compression, either zlib or snappy, I get tons of NullPointerExceptions thrown:
|
| Comments |
| Comment by Githook User [ 11/Dec/17 ] |
|
Author: {'name': 'Jeff Yemin', 'email': 'jeff.yemin@10gen.com', 'username': 'jyemin'}Message: |
| Comment by Githook User [ 11/Dec/17 ] |
|
Author: {'name': 'Jeff Yemin', 'email': 'jeff.yemin@10gen.com', 'username': 'jyemin'}Message: |
| Comment by Scott Lipcon [ 08/Dec/17 ] |
|
Jeff - sorry this isn't more scientific - but using wireshark I was able to see that when I request no compression from my client, the data is in semi-plain text - e.g. I can see very readable snippets of strings from my data in the stream. When I enable zlib compression, the data is completely binary, so that appears to be working - although at an initial glance, the bandwidth is not significantly less, and my application's performance is not significantly better. When I enable snappy compression, the data looks to be plain text - I did read that snappy requires some additional dependency jars, which I installed (snappy-java-1.1.7.jar) but it doesn't appear to be working - I don't see any errors or warnings either with or without that jar on my classpath. Although realistically since the zlib compression didn't seem to help my performance, I don't think snappy would either. Back to trying to do smarter queries.... thanks for your help. |
| Comment by Scott Lipcon [ 08/Dec/17 ] |
|
I tried both zlib and snappy. Both are enabled on my server, and I tried enabling them one at a time in the MongoClientOptions. I was out of the office today at a meeting, so I didn't have time yet to investigate further - I will try to do that tomorrow and get back to you. Is this jira ticket appropriate for further discussion or is there a better avenue? (Note that I upgraded our codebase to 3.6.0 specifically to try compression, to help with a performance issue - I suspect there are other approaches in terms of smarter formatting of the documents on disk to enable better queries, etc, but was hoping compression would help. ) |
| Comment by Jeffrey Yemin [ 06/Dec/17 ] |
|
Interesting. Which compressor did you enable? |
| Comment by Scott Lipcon [ 06/Dec/17 ] |
|
Thanks - I didn't realize it was only a logging issue - I see next to no performance gain by using compression unfortunately for my workload. Need to confirm with wireshark or similar that the utilized bandwidth is actually less. |
| Comment by Jeffrey Yemin [ 06/Dec/17 ] |
|
I've reproduced the issue. Our regression tests didn't catch this because the exception doesn't actually escape the driver. Rather, what you're seeing is the driver's own logging of the exception here. If you want to suppress those log messages, set the logging level for "org.mongodb.driver.protocol.event" to ERROR. |