Hi Giraldo, this is a 100% bug. Let me check in... Lvc@
On 28 March 2014 02:03, Giraldo Rosales <[email protected]> wrote: > Seems to be similar to this problem: > > http://stackoverflow.com/questions/22058416/error-in-connecting-to-orient-db-via-jdbc-drivers > > It was giving me a warning when using a memory database, same as the link > above. But I replaced the database directory with a fresh copy that just > had GratefulDeadConcerts. With a fresh build, it still gave me the > "java.lang.NullPointerException" error when running the binary commands in > the order I have posted below. > > Any thoughts or solutions? Is this a known bug or should it be added to > the queue? > > Thanks, > Giraldo > > > > On Wednesday, March 26, 2014 10:23:03 PM UTC-4, Giraldo Rosales wrote: >> >> When converting the buffer to a string, it returns: >> >> |java.lang.NullPointerExceptionάsrjava.lang.NullPointerExceptionG1xrjava. >> lang.RuntimeException_G >> >> detailMessagetLjava/lang/String;[va.lang.Throwable5' >> 9wLcausetLjava/lang/Throwable;L >> >> stackTracet[Ljava/lang/StackTraceElement;LsuppressedExceptionstLjava/ >> util/List;xpqpur[Ljava.lang.StackTraceElement;F*<<"9xp >> >> >> >> srava.lang.StackTraceElementa Ś&6݅I >> >> lineNumberLdeclaringClassq~fileNameq~L >> >> methodNameq~xpRtCcom.orientechnologies.orient.core.record. >> ORecordSchemaAwareAbstracttORecordSchemaAwareAbstract. >> javatgetSchemaClasssq~ >> >> >> >> Uticom.orientechnologies.orient.core.serialization. >> serializer.record.string.ORecordSerializerSchemaAware2CSVt% >> ORecordSerializerSchemaAware2CSV.javatoStringsq~ >> >> >> >> \thcom.orientechnologies.orient.core.serialization. >> serializer.record.string.ORecordSerializerStringAbstractt$ >> ORecordSerializerStringAbstract.javatoStreamsq~ >> >> >> q~q~q~sq~ >> >> q~q~sq~ >> q~ >> >> q~q~sq~q~ >> >> t7com.orientechnologies.orient.core.record.impl. >> ODocumenttODocument.javaq~sq~ >> >> >> tRcom.orientechnologies.orient.server.network. >> protocol.binary.ONetworkProtocolBilistDatabasessq~ocolBinary.javat >> >> q~q~ texecuteRequestsq~ >> >> ~tZcom.orientechnologies. >> orient.server.network.protocol.binary.OBinaryNetworkProtocolAbstractt# >> OBinaryNetworkProtocolAbstract.javatexecutesq~ >> >> -t/com.orientechnologies.common.thread. >> OSoftThreadtOSoftThread.javatrunsr&java.util. >> Collections$UnmodifiableList%1Llistq~xr,java.util.Collections$ >> UnmodifiableCollectionB^LctLjava/util/Collection;xpsrjava.util. >> ArrayListxaIsizexpwxq~1x >> >> >> >> >> On Wednesday, March 26, 2014 5:43:28 PM UTC-4, Giraldo Rosales wrote: >>> >>> When running REQUEST_DB_LIST by itself after REQUEST_CONNECT, runs fine, >>> returns the single database, >>> >>> GratefulDeadConcerts. When running the following sequence, >>> >>> REQUEST_CONNECT >>> REQUEST_DB_EXIST >>> REQUEST_DB_LIST >>> >>> Where the params for db exists is either a non-existent db or the >>> GratefulDeadConcerts db. The buffer for the REQUEST_DB_LIST comes back >>> invalid. It seems to have a larger buffer length than when leaving out >>> REQUEST_DB_EXIST. Why is the buffer length coming in at different sizes? >>> Using the latest binary, 1.7 >>> >> -- > > --- > You received this message because you are subscribed to the Google Groups > "OrientDB" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
