2016-11-03 6 views
0

Unter Windows, mit dem Cassandra Java-Treiber, bekomme ich manchmal und AccessControlException für die Datei logback.xml im Cassandra-Installationsverzeichnis. Ich verwende log4j, nicht Logback.Cassandra Java Client: AccessControlException: Zugriff verweigert auf "C: Programme DataStax-DDC apache-cassandra conf logback.xml" "lesen")

Die Abfrage funktioniert mit einem kleinen Datensatz, schlägt aber mit dieser oder einer CodecNotFoundException für einen großen Datensatz fehl.

Es ist wahrscheinlich, dass die AccessControlException eine andere Ausnahme (z. B. Timeout) maskiert.

1) Warum sollte der Client die Logback-Konfiguration an erster Stelle lesen und warum aus dem Installationsverzeichnis?

2) Wie kann ich einen anderen Suchpfad für die Logback-Konfigurationsdatei konfigurieren?

Die Ausnahmemeldung:

com.datastax.driver.core.exceptions.FunctionExecutionException: execution of 'average_by_source_1[avg_type_1, text, double]' failed: java.security.AccessControlException: access denied ("java.io.FilePermission" "C:\Program Files\DataStax-DDC\apache-cassandra\conf\logback.xml" "read") 
     at com.datastax.driver.core.Responses$Error.asException(Responses.java:130) 
     at com.datastax.driver.core.DefaultResultSetFuture.onSet(DefaultResultSetFuture.java:179) 
     at com.datastax.driver.core.RequestHandler.setFinalResult(RequestHandler.java:174) 
     at com.datastax.driver.core.RequestHandler.access$2600(RequestHandler.java:43) 
     at com.datastax.driver.core.RequestHandler$SpeculativeExecution.setFinalResult(RequestHandler.java:793) 
     at com.datastax.driver.core.RequestHandler$SpeculativeExecution.onSet(RequestHandler.java:627) 
     at com.datastax.driver.core.Connection$Dispatcher.channelRead0(Connection.java:1012) 
     at com.datastax.driver.core.Connection$Dispatcher.channelRead0(Connection.java:935) 
     at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105) 
     at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342) 
     at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:328) 
     at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:321) 
     at io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:266) 
     at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342) 
     at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:328) 
     at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:321) 
     at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102) 
     at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342) 
     at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:328) 
     at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:321) 
     at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:293) 
     at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:267) 
     at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342) 
     at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:328) 
     at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:321) 
     at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1280) 
     at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342) 
     at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:328) 
     at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:890) 
     at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131) 
     at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:564) 
     at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:505) 
     at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:419) 
     at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:391) 
     at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112) 
     at java.lang.Thread.run(Unknown Source) 

Antwort

1

Das durch diese Cassandra verursacht wird bug

Was passiert, ist, dass die UDF ohne Dateizugriff in einer Sandbox ausgeführt wird. Das von Cassandra verwendete Protokollierungs-Framework hat die Angewohnheit, die Datei conf/logback.xml von Zeit zu Zeit erneut zu lesen. Wenn das erneute Lesen geschieht, während Cassandra die UDF ausführt, erhält man diesen zufälligen Fehler.

Sollte in 3.10

Als Abhilfe kann in 3.9 behoben werden Sie <configuration scan="false"> an der Spitze des /conf/logback.xml einstellen können, keine Notwendigkeit, neu zu starten, wie es sich bis auf dem nächsten Wieder Scan abholt

Verwandte Themen