[ 
https://issues.apache.org/jira/browse/CASSANDRA-13333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15929645#comment-15929645
 ] 

Benjamin Lerer edited comment on CASSANDRA-13333 at 3/17/17 9:29 AM:
---------------------------------------------------------------------

I went to look into how the things were working before the CASSANDRA-13233 
changes.
The code does a difference between JNA not being there and the fact that it 
could not link a library. In the first case {{jnaAvailable()}} must return 
{{false}} but in the second case it should return {{true}} (and an error 
message should have been logged). The new implementation always return 
{{false}} even if the library is actually there.
So, to keep the existing behaviour, we would need to check if JNA is here and 
throw the appropriate errors. The easier way would probably to also have the 
following code in {{CLibraryWindows}} but it feels a bit weird:
{code}
        try
        {
            Native.register("c");
        }
        catch (NoClassDefFoundError e)
        {
            logger.warn("JNA not found. Native methods will be disabled.");
            jnaAvailable = false;
        }
        catch (UnsatisfiedLinkError e)
        {
            logger.warn("JNA link failure, one or more native method will be 
unavailable.");
            logger.trace("JNA link failure details: {}", e.getMessage());
        }
        catch (NoSuchMethodError e)
        {
            logger.warn("Obsolete version of JNA present; unable to register C 
library. Upgrade to JNA 3.2.7 or later");
            jnaAvailable = false;
        }
{code} 

Any suggestions?


was (Author: blerer):
I went to look into how the things were working before the CASSANDRA-13233 
changes.
The code does a difference between JNA not being there and the fact that it 
could not link a library. In the first case {{jnaAvailable()}} must return 
{{false}} but in the second case it should return true (and an error message 
should have been logged). The new implementation always return {{false}} even 
if the library is actually there.
So to keep the existing behaviour we would need to check if JNA is here and 
throw the appropriate errors. The easier way would probably to also have the 
following code in {{CLibraryWindows}} but it feels a bit weird:
{code}
        try
        {
            Native.register("c");
        }
        catch (NoClassDefFoundError e)
        {
            logger.warn("JNA not found. Native methods will be disabled.");
            jnaAvailable = false;
        }
        catch (UnsatisfiedLinkError e)
        {
            logger.warn("JNA link failure, one or more native method will be 
unavailable.");
            logger.trace("JNA link failure details: {}", e.getMessage());
        }
        catch (NoSuchMethodError e)
        {
            logger.warn("Obsolete version of JNA present; unable to register C 
library. Upgrade to JNA 3.2.7 or later");
            jnaAvailable = false;
        }
{code} 

Any suggestions?

> Cassandra does not start on Windows due to 'JNA link failure'
> -------------------------------------------------------------
>
>                 Key: CASSANDRA-13333
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13333
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Benjamin Lerer
>            Assignee: Benjamin Lerer
>            Priority: Blocker
>
> Cassandra 3.0 HEAD does not start on Windows. The only error in the logs is: 
> {{ERROR 16:30:10 JNA failing to initialize properly.}} 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to