vert.x getting - failed to create a child event loop - java

I am creating about 150 files of around 5MB sizes. Vertx file APIs gives an exception randomly after creating 10-15 files "failed to create a child event loop".
(I am using vertx3 and java8)
Below is my code snippet (After I get a callback then only I call the function again to create the next file. So, file creation is never concurrent):
Vertx.vertx().fileSystem().writeFile(filepath,
Buffer.buffer(dataList.toString()), result -> {
if (result.succeeded()) {
System.out.println("File written");
} else {
System.err.println("Oh oh ..." + result.cause());
}
lambda.callback();
});
Below is my exception stack trace:
java.lang.IllegalStateException: failed to create a child event loop
at io.netty.util.concurrent.MultithreadEventExecutorGroup.<init>(MultithreadEventExecutorGroup.java:68)
at io.netty.channel.MultithreadEventLoopGroup.<init>(MultithreadEventLoopGroup.java:49)
at io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:61)
at io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:52)
at io.vertx.core.impl.VertxImpl.<init>(VertxImpl.java:132)
at io.vertx.core.impl.VertxImpl.<init>(VertxImpl.java:126)
at io.vertx.core.impl.VertxImpl.<init>(VertxImpl.java:122)
at io.vertx.core.impl.VertxFactoryImpl.vertx(VertxFactoryImpl.java:34)
at io.vertx.core.Vertx.vertx(Vertx.java:78)
at rc_datawarehouse.CsvToJsonChunkWriter.writeCsvChunkToFiles(CsvToJsonChunkWriter.java:73)
at rc_datawarehouse.CsvToJsonReadWrite.lambda$2(CsvToJsonReadWrite.java:119)
at rc_datawarehouse.CsvToJsonReadWrite$$Lambda$16/1470881859.handle(Unknown Source)
at io.vertx.core.file.impl.AsyncFileImpl.handleData(AsyncFileImpl.java:335)
at io.vertx.core.file.impl.AsyncFileImpl.lambda$doRead$285(AsyncFileImpl.java:320)
at io.vertx.core.file.impl.AsyncFileImpl$$Lambda$17/1067800899.handle(Unknown Source)
at io.vertx.core.file.impl.AsyncFileImpl$2.lambda$done$289(AsyncFileImpl.java:408)
at io.vertx.core.file.impl.AsyncFileImpl$2$$Lambda$18/1632681662.handle(Unknown Source)
at io.vertx.core.impl.ContextImpl.lambda$wrapTask$15(ContextImpl.java:314)
at io.vertx.core.impl.ContextImpl$$Lambda$5/1780132728.run(Unknown Source)
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:357)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357)
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:111)
at java.lang.Thread.run(Unknown Source)
Caused by: io.netty.channel.ChannelException: failed to open a new selector
at io.netty.channel.nio.NioEventLoop.openSelector(NioEventLoop.java:128)
at io.netty.channel.nio.NioEventLoop.<init>(NioEventLoop.java:120)
at io.netty.channel.nio.NioEventLoopGroup.newChild(NioEventLoopGroup.java:87)
at io.netty.util.concurrent.MultithreadEventExecutorGroup.<init>(MultithreadEventExecutorGroup.java:64)
... 22 more
Caused by: java.io.IOException: Unable to establish loopback connection
at sun.nio.ch.PipeImpl$Initializer.run(Unknown Source)
at sun.nio.ch.PipeImpl$Initializer.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.nio.ch.PipeImpl.<init>(Unknown Source)
at sun.nio.ch.SelectorProviderImpl.openPipe(Unknown Source)
at java.nio.channels.Pipe.open(Unknown Source)
at sun.nio.ch.WindowsSelectorImpl.<init>(Unknown Source)
at sun.nio.ch.WindowsSelectorProvider.openSelector(Unknown Source)
at io.netty.channel.nio.NioEventLoop.openSelector(NioEventLoop.java:126)
... 25 more
Caused by: java.net.SocketException: No buffer space available (maximum connections reached?): connect
at sun.nio.ch.Net.connect0(Native Method)
at sun.nio.ch.Net.connect(Unknown Source)
at sun.nio.ch.Net.connect(Unknown Source)
at sun.nio.ch.SocketChannelImpl.connect(Unknown Source)
at java.nio.channels.SocketChannel.open(Unknown Source)
at sun.nio.ch.PipeImpl$Initializer$LoopbackConnector.run(Unknown Source)
... 34 more

I got my answer from the forum here (Thanks Jez)
Vertx.vertx() is the culprit. It creates a new vertx every time leading to multiple eventloops which seems to be the problem.
I cached it in a variable, rather than using Vertx.vertx() every time and it worked
cachedVertx.fileSystem().writeFile(...)

Related

java.sql.SQLException: JZ006: Caught IOException: java.net.SocketTimeoutException: Read timed out use getCause() to see the error chain

We are masking Sybase database using a third party tool written in Java. I am getting below error intermittently while masking a table of Sybase database. If I just re-execute the batch, it works fine so being really difficult to reproduce.
2020-01-09 04:41:55.657 Thread:Table Name - Error executing select statement for update
2020-01-09 04:41:55.657 Error Executing Batch
java.sql.SQLException: JZ006: Caught IOException: java.net.SocketTimeoutException: Read timed
out use getCause() to see the error chain
at com.sybase.jdbc4.jdbc.ErrorMessage.raiseError(ErrorMessage.java:829)
at com.sybase.jdbc4.jdbc.ErrorMessage.raiseErrorCheckDead(ErrorMessage.java:1141)
at com.sybase.jdbc4.tds.Tds.handleIOE(Tds.java:5186)
at com.sybase.jdbc4.tds.Tds.handleIOE(Tds.java:5131)
at com.sybase.jdbc4.tds.Tds.nextResult(Tds.java:2921)
at com.sybase.jdbc4.tds.TdsCursor.fetch(TdsCursor.java:422)
at com.sybase.jdbc4.tds.TdsCursor.fetch(TdsCursor.java:351)
at com.sybase.jdbc4.jdbc.SybCursorResultSet.next(SybCursorResultSet.java:187)
at com.grid_tools.products.datamasker.SQLUpdate.batchPreparedMasking(SQLUpdate.java:2706)
at com.grid_tools.products.datamasker.SQLUpdate.run(SQLUpdate.java:5717)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
at com.sybase.jdbc4.timedio.RawDbio.reallyRead(RawDbio.java:322)
at com.sybase.jdbc4.timedio.Dbio.doRead(Dbio.java:253)
at com.sybase.jdbc4.timedio.InStreamMgr.readIfOwner(InStreamMgr.java:583)
at com.sybase.jdbc4.timedio.InStreamMgr.doRead(InStreamMgr.java:319)
at com.sybase.jdbc4.tds.TdsProtocolContext.getChunk(TdsProtocolContext.java:622)
at com.sybase.jdbc4.tds.PduInputFormatter.readPacket(PduInputFormatter.java:239)
at com.sybase.jdbc4.tds.PduInputFormatter.read(PduInputFormatter.java:72)
at com.sybase.jdbc4.tds.TdsInputStream.read(TdsInputStream.java:91)
at com.sybase.jdbc4.tds.TdsInputStream.readUnsignedByte(TdsInputStream.java:124)
at com.sybase.jdbc4.tds.Tds.nextResult(Tds.java:2879)
WHERE "row_id" = ?
This is because of network issue at your end.. Probably your internet is not sable there.

Lambda stack trace missing when using NativeMethodAccessor instead of GeneratedMethodAccessor

A couple days ago, I got a support ticket for this NullPointerException:
com.google.gwt.user.server.rpc.UnexpectedException: Service method 'public abstract com.redacted.SalesResponsePagination com.redacted.StatisticsService.findSalesData(com.redacted.ConfStats) throws com.redacted.AsyncException' threw an unexpected exception: java.lang.NullPointerException
at com.google.gwt.user.server.rpc.RPC.encodeResponseForFailure(RPC.java:389)
at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:579)
at ... (typical GWT + Tomcat stacktrace)
Caused by: java.lang.NullPointerException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.util.concurrent.ForkJoinTask.getThrowableException(Unknown Source)
at java.util.concurrent.ForkJoinTask.reportException(Unknown Source)
at java.util.concurrent.ForkJoinTask.invoke(Unknown Source)
at java.util.stream.ForEachOps$ForEachOp.evaluateParallel(Unknown Source)
at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(Unknown Source)
at java.util.stream.AbstractPipeline.evaluate(Unknown Source)
at java.util.stream.ReferencePipeline.forEach(Unknown Source)
at com.redacted.StatisticsControllerImpl.replacePrices(StatisticsControllerImpl.java:310)
at com.redacted.StatisticsControllerImpl.findSalesData(StatisticsControllerImpl.java:288)
at com.redacted.StatisticsServiceImpl.findSalesData(StatisticsServiceImpl.java:83)
at sun.reflect.GeneratedMethodAccessor752.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:561)
... 33 more
Caused by: java.lang.NullPointerException
at com.redacted.StatisticsControllerImpl.lambda$replacePrices$27(StatisticsControllerImpl.java:317)
at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(Unknown Source)
at ... (typical stream.forEach stacktrace)
Now, this was an easy one because the exact line number for the NPE was in plain sight; all I had to do was go to StatisticsControllerImpl.java:317:
salesResponsePagination.getSalesResponses().parallelStream()
.peek(sr -> /*...*/)
.filter(sr -> /*...*/)
/*310*/ .forEach(sr -> {
final List<CartElement> sentCEs = DaoService.getCartElementDAO().getSentCEs(/*...*/);
if (sentCEs != null && !sentCEs.isEmpty() && sentCEs.get(0) != null) {
final CartElement ce = sentCEs.get(0);
// some more non-NPE lines...
/*317*/ if (sr.getCurrency().equals(ce.getPurchaseCurrency()) && sr.getPrice().equals(ce.getPurchasePrice().intValue()) && !ce.getCurrency().equals(ce.getPurchaseCurrency())) {
// Some currency exchanging
}
// Etcetera (about 12 lines more)
});
And replace the .equals() calls with Object.equals() to avoid the NPE (investigating the reasons why some sales were registered with a NULL price or currency came later). Test, commit, push, send ticket to QA.
However, the next day QA returned the ticket saying that the NPE persisted, and they included a new, almost similar stack trace:
com.google.gwt.user.server.rpc.UnexpectedException: Service method 'public abstract com.redacted.SalesResponsePagination com.redacted.StatisticsService.findSalesData(com.redacted.ConfStats) throws com.redacted.AsyncException' threw an unexpected exception: java.lang.NullPointerException
at com.google.gwt.user.server.rpc.RPC.encodeResponseForFailure(RPC.java:389)
at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:579)
at ... (typical GWT + Tomcat stacktrace)
Caused by: java.lang.NullPointerException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.util.concurrent.ForkJoinTask.getThrowableException(Unknown Source)
at java.util.concurrent.ForkJoinTask.reportException(Unknown Source)
at java.util.concurrent.ForkJoinTask.invoke(Unknown Source)
at java.util.stream.ForEachOps$ForEachOp.evaluateParallel(Unknown Source)
at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(Unknown Source)
at java.util.stream.AbstractPipeline.evaluate(Unknown Source)
at java.util.stream.ReferencePipeline.forEach(Unknown Source)
at com.redacted.StatisticsControllerImpl.replacePrices(StatisticsControllerImpl.java:310)
at com.redacted.StatisticsControllerImpl.findSalesData(StatisticsControllerImpl.java:288)
at com.redacted.StatisticsServiceImpl.findSalesData(StatisticsServiceImpl.java:83)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:561)
... 33 more
Caused by: java.lang.NullPointerException
This stack trace was exactly the same as the previous one, except for two things:
This call was using NativeMethodAccessorImpl instead of GeneratedMethodAccessor752. Compare:
at com.redacted.StatisticsServiceImpl.findSalesData(StatisticsServiceImpl.java:83)
at sun.reflect.GeneratedMethodAccessor752.invoke(Unknown Source)
vs
at com.redacted.StatisticsServiceImpl.findSalesData(StatisticsServiceImpl.java:83)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
This one was missing the stack trace for the lambda. The line where the NPE happened was missing.
This threw me off initially. Why was the last part of the stack trace missing? I asked QA to re-test and re-attach the stack trace a couple times, until I got a complete one; however, the complete one I got in the end was based on GeneratedMethodAccesor once again.
Now, if I understand correctly, sun.reflect.NativeMethodAccessorImpl is used for the first invocations of a method, until JIT has enough info to generate an optimized accesor for that method in the form of sun.reflect.GeneratedMethodAccessorNNN.
What I don't understand is: if Native is using my code and Generated is using JIT's generated code, shouldn't Native show more info about my code, not less?
So my question is:
Why do lambda runtime exceptions thrown inside sun.reflect.NativeMethodAccessorImpl seem to be missing the lambda's stack trace?
Can this be a bug in JDK's source code? Especially when the very same exception thrown inside sun.reflect.GeneratedMethodAccessor includes the lambda stack trace without problem.
The following code manages to get a stack trace similar to the first one. I can force the use of NativeMethodAccessor or GeneratedMethodAccesor by running it with a sufficiently low or high first parameter, respectively (i.e. java test.Main 1 or java test.Main 30).
However, the lambda part of it is always present, whether using Native or Generated.
package test;
import java.lang.reflect.Method;
import java.util.stream.IntStream;
class MyOtherClass {
public void methodWithLambda(boolean fail) {
IntStream.range(0, 1000).parallel().forEach(k -> {
if (fail && k % 500 == 0)
throw new NullPointerException();
});
}
public String methodProxy(boolean fail) {
methodWithLambda(fail);
return "OK";
}
}
class MyClass {
public String methodReflected(Boolean fail) {
return new MyOtherClass().methodProxy(fail);
}
}
class Main {
public static void main(String[] args) throws Exception {
Class<MyClass> clazz = MyClass.class;
Object instance = clazz.newInstance();
Method method = clazz.getMethod("methodReflected", Boolean.class);
int reps = args.length >= 1 ? Integer.valueOf(args[0]) : 20;
for (; reps --> 0;) {
// Several non-failing calls to force creation of GeneratedMethodAccesor
System.out.println((String) method.invoke(instance, false));
}
// Failing call
System.out.println((String) method.invoke(instance, true));
}
}
Stack trace for the above code when using NativeMethodAccesor:
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at test.Main.main(Main.java:36)
Caused by: java.lang.NullPointerException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.util.concurrent.ForkJoinTask.getThrowableException(Unknown Source)
at java.util.concurrent.ForkJoinTask.reportException(Unknown Source)
at java.util.concurrent.ForkJoinTask.invoke(Unknown Source)
at java.util.stream.ForEachOps$ForEachOp.evaluateParallel(Unknown Source)
at java.util.stream.ForEachOps$ForEachOp$OfInt.evaluateParallel(Unknown Source)
at java.util.stream.AbstractPipeline.evaluate(Unknown Source)
at java.util.stream.IntPipeline.forEach(Unknown Source)
at java.util.stream.IntPipeline$Head.forEach(Unknown Source)
at test.MyOtherClass.methodWithLambda(Main.java:8)
at test.MyOtherClass.methodProxy(Main.java:14)
at test.MyClass.methodReflected(Main.java:21)
... 5 more
Caused by: java.lang.NullPointerException
at test.MyOtherClass.lambda$methodWithLambda$0(Main.java:10)
at java.util.stream.ForEachOps$ForEachOp$OfInt.accept(Unknown Source)
at java.util.stream.Streams$RangeIntSpliterator.forEachRemaining(Unknown Source)
at java.util.Spliterator$OfInt.forEachRemaining(Unknown Source)
at java.util.stream.AbstractPipeline.copyInto(Unknown Source)
at java.util.stream.ForEachOps$ForEachTask.compute(Unknown Source)
at java.util.concurrent.CountedCompleter.exec(Unknown Source)
at java.util.concurrent.ForkJoinTask.doExec(Unknown Source)
at java.util.concurrent.ForkJoinPool$WorkQueue.execLocalTasks(Unknown Source)
at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(Unknown Source)
at java.util.concurrent.ForkJoinPool.runWorker(Unknown Source)
at java.util.concurrent.ForkJoinWorkerThread.run(Unknown Source)
EDIT: Just to be clear: I am not looking for ways to fix this NPE, nor ways to force the lambda's stack trace to print. What I want to know is the reason why the above happens: different implementations? A bug? Something to do with forEach()?
This might be an issue of JDK-6678999, “Stacktrace missing after null string comparisons”:
After comparing a string to null and catching the exception and repeating the operation, JVM starts throwing "stackless" NullPointerException (it occurs after 9000 loops but this is variable)
The evaluation of the issue is
When the server compiler compiles a method, the stack trace in an exception thrown
by that method may be omitted for performance purposes.
[…] If the user always wants stack traces, use the -XX:-OmitStackTraceInFastThrow option to the VM.
So, the option -XX:-OmitStackTraceInFastThrow may solve the issue.
Note that the bug report was against Java 6, but since it has been closed as “Won't Fix”, it may still be relevant, though you would have to replace “server compiler” with “c2 compiler” in the explanation now.
The use of NativeMethodAccessorImpl or GeneratedMethodAccessor… is not relevant to this issue, except that both have a common cause; a higher number of executions may trigger the optimizations.

"java.net.SocketException: Connection reset" when running a simpleSSL client

I am attempting to create a client/server using the SSL communication. I followed the instructions listed here (https://www.rabbitmq.com/ssl.html).
I am greeted with this error:
while running the server :
java.net.SocketException: Connection reset
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:113)
at java.net.SocketOutputStream.write(SocketOutputStream.java:153)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
at java.io.DataOutputStream.flush(DataOutputStream.java:123)
at com.rabbitmq.client.impl.SocketFrameHandler.sendHeader(SocketFrameHandler.java:129)
at com.rabbitmq.client.impl.SocketFrameHandler.sendHeader(SocketFrameHandler.java:134)
at com.rabbitmq.client.impl.AMQConnection.start(AMQConnection.java:277)
at com.rabbitmq.client.ConnectionFactory.newConnection(ConnectionFactory.java:678)
at com.rabbitmq.client.ConnectionFactory.newConnection(ConnectionFactory.java:722)
while using the client :
Exception in thread "main" java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
at sun.security.ssl.InputRecord.readFully(Unknown Source)
at sun.security.ssl.InputRecord.read(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.waitForClose(Unknown Source)
at sun.security.ssl.HandshakeOutStream.flush(Unknown Source)
at sun.security.ssl.Handshaker.kickstart(Unknown Source)
at sun.security.ssl.SSLSocketImpl.kickstartHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.writeRecord(Unknown Source)
at sun.security.ssl.AppOutputStream.write(Unknown Source)
at java.io.BufferedOutputStream.flushBuffer(Unknown Source)
at java.io.BufferedOutputStream.flush(Unknown Source)
at java.io.DataOutputStream.flush(Unknown Source)
at com.rabbitmq.client.impl.SocketFrameHandler.sendHeader(SocketFrameHandler.java:129)
at com.rabbitmq.client.impl.SocketFrameHandler.sendHeader(SocketFrameHandler.java:134)
at com.rabbitmq.client.impl.AMQConnection.start(AMQConnection.java:277)
at com.rabbitmq.client.ConnectionFactory.newConnection(ConnectionFactory.java:678)
at com.rabbitmq.client.ConnectionFactory.newConnection(ConnectionFactory.java:722)
at rmqClient.simpleSSL.main(simpleSSL.java:23)
here's my rabbit.config file :
[
{ssl, [{versions, ['tlsv1.2', 'tlsv1.1']}]},
{
rabbit,
[
{ssl_listeners, [5675]},
{ssl_options, [{cacertfile,"sslConn/ca_certificate.pem"},
{certfile, "sslConn/server_certificate.pem"},
{keyfile, "sslConn/server_key.pem"},
{versions, ['tlsv1.2', 'tlsv1.1']},
{ciphers, [{ecdhe_ecdsa,aes_128_cbc,sha256},
{ecdhe_ecdsa,aes_256_cbc,sha}]}
]},
{tcp_listeners, [5672]},
{loopback_users, []}
]
}
].
here's also my client code :
factory.setHost("10.3.9.139");
factory.setPort(5673);
factory.setUsername("User1");
factory.setPassword("User1");
factory.useSslProtocol();
Connection conn = factory.newConnection();
Channel channel = conn.createChannel();
channel.queueDeclare("rabbitmq-java-test", false, true, true, null);
channel.basicPublish("", "rabbitmq-java-test", null, "Hello, World".getBytes());
java.net.SocketException: Connection reset is generally speaking caused by remote peer closed connection.
I guess your SSL config didn't fit well with server.
Suggestion here is to debug SSL connection to find root cause.
Try to append this system property to your JVM params:
-Djavax.net.debug=all
More details here
I was able to fix this in Java 1.7 by specifying:
SSLContext sc = SSLContext.getInstance("TLSv1.2");
In the v configuration you have set port 5675 for SSL listener, but in code you are using 5673.

Call to Cipher.getInstance makes an ftp call

My application makes call to Cipher.getInstance so it can decrypt passwords.
In certain environments this is creating a problem because the Cipher.getInstance method ends up trying to make an FTP call which is hanging.
Does anyone know how to avoid this FTP call or prevent it hanging?
Here is the stacktrace.
java.net.PlainSocketImpl.socketConnect(Native Method)
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:370)
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:231)
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:213)
java.net.Socket.connect(Socket.java:643)
java.net.Socket.connect(Socket.java:590)
sun.net.ftp.impl.FtpClient.doConnect(FtpClient.java:971)
sun.net.ftp.impl.FtpClient.tryConnect(FtpClient.java:931)
sun.net.ftp.impl.FtpClient.connect(FtpClient.java:1026)
sun.net.ftp.impl.FtpClient.connect(FtpClient.java:1012)
sun.net.www.protocol.ftp.FtpURLConnection.connect(FtpURLConnection.java:307)
sun.net.www.protocol.ftp.FtpURLConnection.getInputStream(FtpURLConnection.java:406)
sun.net.www.protocol.jar.URLJarFile.retrieve(URLJarFile.java:227)
sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:84)
sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:128)
sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:136)
sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:103)
javax.crypto.a$0.run(Unknown Source)
java.security.AccessController.doPrivileged(AccessController.java:420)
javax.crypto.a.a(Unknown Source)
javax.crypto.a.a(Unknown Source)
javax.crypto.a.a(Unknown Source)
javax.crypto.b.a(Unknown Source)
javax.crypto.d.a(Unknown Source)
javax.crypto.d.a(Unknown Source)
javax.crypto.Cipher.c(Unknown Source)
javax.crypto.Cipher.b(Unknown Source)
javax.crypto.Cipher.getInstance(Unknown Source)
javax.crypto.Cipher.getInstance(Unknown Source)

App Engine / Quercus datastore prepare query error

I'm trying to replicate the java guestbook example on Quercus on AppEngine and I'm getting an error having to do with preparing the query:
$greetings = $datastore->prepare($query)->asIterable();
I'm not a java developer so I can't make sense of the error trace. How can I get the greeting items without triggering this error?
Here is the entire error page:
HTTP ERROR 500
Problem accessing /index.php. Reason:
INTERNAL_SERVER_ERROR
Caused by:
java.lang.NullPointerException at
com.google.appengine.api.datastore.dev.LocalDatastoreService.next(LocalDatastoreService.java:1089)
at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source) at
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at
java.lang.reflect.Method.invoke(Unknown Source) at
com.google.appengine.tools.development.ApiProxyLocalImpl$AsyncApiCall.callInternal(ApiProxyLocalImpl.java:498)
at
com.google.appengine.tools.development.ApiProxyLocalImpl$AsyncApiCall.call(ApiProxyLocalImpl.java:452)
at
com.google.appengine.tools.development.ApiProxyLocalImpl$AsyncApiCall.call(ApiProxyLocalImpl.java:430)
at java.util.concurrent.Executors$PrivilegedCallable$1.run(Unknown
Source) at java.security.AccessController.doPrivileged(Native Method)
at java.util.concurrent.Executors$PrivilegedCallable.call(Unknown
Source) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown
Source) at java.util.concurrent.FutureTask.run(Unknown Source) at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
If it's a null pointer exception then you are trying to access a method or property of a null object
First you need to check if $datastore is null, then if the return of the query is not null. Also you need to check if that error is on that particular line of code (maybe it fails somewhere else)
You can access the database at this link /_ah/admin. Maybe there is a corrupt entity in there

Categories