You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Benjamin Lerer (JIRA)" <ji...@apache.org> on 2017/03/17 09:28:41 UTC

[jira] [Comment Edited] (CASSANDRA-13333) Cassandra does not start on Windows due to 'JNA link failure'

    [ 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:28 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 your change.
The code does a difference between JNA not being there (jna jar not being in the classpath) 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 in the classpath 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)