Am 2015-08-28 um 21:22 schrieb Alexander Bernstein:
Thank you, Michael. I too noticed that the code was marked as
experimental. I have a workaround for this issue (simply keep the
references to the created WindowsNegotiateScheme objects and dispose
of them before GC gets to them. This works for me.
It is always a good decision to release resources as soon as you don't
need them. Even in Java with sockets or streams.
Having said that,
should I expect more problems later? If these are known issues, are
there others?
There are at least three issues with JNA in HttpClient:
1. https://issues.apache.org/jira/browse/HTTPCLIENT-1561 due to
https://github.com/java-native-access/jna/issues/381
2. https://issues.apache.org/jira/browse/HTTPCLIENT-1582
MAX_TOKEN_SIZE is a const value. Might cause problems if the token is
bigger than this. Ideally, the client will request the system to
allocate memory for it.
3: https://issues.apache.org/jira/browse/HTTPCLIENT-1598
Maybe others.
Now, this code is experimental which I can understand, so I ran an
experiment and found a problem. But putting something untested/not
reviewed into production (the released libraries in this case) seems
dangerous to me. I am not questioning your practices or anything,
just a side comment.
It is completely up to you if you wan't to rely on this code. If you can
live with the issues that is fine.
Here is a writeup I have created on the issue several months ago:
http://mail-archives.apache.org/mod_mbox/hc-dev/201504.mbox/%3c552c2b3b.9060...@apache.org%3E
Please read the entire thread.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
