what could be the reason that Luna HSM is throwing the below exception:
com.safenetinc.luna.exception.LunaCryptokiException: function 'C_Decrypt' returns 0x5 (CKR_GENERAL_ERROR)
at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2202) ~[na:na]
PS: it is able to load key using the provided key alias.
CKR_GENERAL_ERROR in PKCS #11 means a crypto operation request by a client failed to complete successfully. This could have happened because the slot an application was using may have gone offline/disconnected/disappeared while a crypto operation was in progress. Or it may have encountered issues such as crash or a halt. In some cases you may see errors such as CKR_DEVICE_ERROR or CKR_TOKEN_NOT_PRESENT after CKR_GENERAL_ERROR.
In your case, something may have happened to the slot while it was still busy processing C_Decrypt().
Related
I am having a program will involves frequently accessing BigQuery using com.google.gcloud:gcloudjava:0.1.4 with default BigQueryOptions configuration
However sometime I am getting error with stacktrace as follows
Caused by: java.io.IOException: Error getting access token for service account:
at com.google.auth.oauth2.ServiceAccountCredentials.refreshAccessToken(ServiceAccountCredentials.java:227)
at com.google.auth.oauth2.OAuth2Credentials.refresh(OAuth2Credentials.java:97)
at com.google.auth.oauth2.OAuth2Credentials.getRequestMetadata(OAuth2Credentials.java:74)
at com.google.auth.http.HttpCredentialsAdapter.initialize(HttpCredentialsAdapter.java:65)
at com.google.gcloud.ServiceOptions$1.initialize(ServiceOptions.java:533)
at com.google.api.client.http.HttpRequestFactory.buildRequest(HttpRequestFactory.java:93)
at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.buildHttpRequest(AbstractGoogleClientRequest.java:300)
at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:419)
at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:352)
at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.execute(AbstractGoogleClientRequest.java:469)
at com.google.gcloud.spi.DefaultBigQueryRpc.query(DefaultBigQueryRpc.java:402)
It only failed from time to time, but I am wondering whether there is any way that I could sort of improve the stability of my program. Therefore just in case I am wondering, it is a pure server side problem that I have no way to do about it or is there any way that I could at client side to potentially decrease the possibility of this happening (say by changing the authentication configuration or anything?)
May be a server side problem with google-oauth. I'm having problems with that as well - services that used to work fine can't get an access token anymore (since about 1h).
From the tutorial session, While I was performing tutorial no 2 suddenly I face error whole I was trying to modify data formula.
The Error is [08S01] Communication link failure
I am new in scribe so, unable to understand exactly what's going on.
So many times ago I face same problem and,
the problem resolved, I just simply restart scribe, and all done...
But As I am thinking this error may be due to the error in connection to the ODBC data connection.
So, in further try to resolve it with ODBC connection.....
I use winverifytrust to validate signature.
I am verifying using WINTRUST_ACTION_GENERIC_VERIFY_V2. But rarely it has returned "NO SIGNATURE FOUND". I am unable to simulate the issue.
I am getting feedback that this is happening in some users. One feedback has a log which indicates that the 1st call to WinVerifyTrust for a file succeeds and the second call to the same file has failed.
The code i used is exactly
http://msdn.microsoft.com/en-us/library/aa382384%28v=VS.85%29.aspx
Any idea what may have caused the failure. Same call to the same file has succeeded once and failed next.
Looking at the MS example you linked if you encounter TRUST_E_NOSIGNATURE then you need to examine GetLastError() for a further TRUST_E_ error code.
Their logic for TRUST_E_NOSIGNATURE also includes;
else
{
// The signature was not valid or there was an error
// opening the file.
So it seems that an IO error could also cause this (a locked file could explain the intermittency) either way GetLastError() should elucidate.
This happens when calling WinVerifyTrust on Windows Server 2008 with a file signed with only SHA-256,
which isn't supported by default on Server 2008, it expects signatures that use SHA-1.
http://winwiki.org/wiki/wikimeta.php?kw=Error+Trust_e_nosignature%280x800b0100%29
The Error Trust_e_nosignature(0x800b0100) error may be caused by windows system files damage.
This article contains information that shows you how to fix Error Trust_e_nosignature(0x800b0100) both (manually) and (automatically).
I'm running two glassfish v2 domains containing stateless session EJBs. In a few cases, an EJB in one domain has to call one in the other.
My problem is that when the called EJB aborts with an exception, the caller does not receive the message of the exception and instead reports an internal error that is not helpful at all in diagnosing the problem. What happens seems to be this:
At the transport layer, a org.omg.CORBA.portable.ApplicationException is created,which already loses all detail information about the exception except its class.
Inside com.sun.jts.CosTransactions.TopCoordinator.get_txcontext(), the status of the transaction ass rolled back causes a org.omg.CosTransactions.Unavailable to be thrown, which gets wrapped and passed around a few times and eventually results into this error being displayed to the user:
org.omg.CORBA.INVALID_TRANSACTION: vmcid: 0x0 minor code: 0 completed: No
at com.sun.jts.CosTransactions.CurrentTransaction.sendingRequest(CurrentTransaction.java:807)
at com.sun.jts.CosTransactions.SenderReceiver.sending_request(SenderReceiver.java:139)
at com.sun.jts.pi.InterceptorImpl.send_request(InterceptorImpl.java:344)
at com.sun.corba.ee.impl.interceptors.InterceptorInvoker.invokeClientInterceptorStartingPoint(InterceptorInvoker.java:271)
at com.sun.corba.ee.impl.interceptors.PIHandlerImpl.invokeClientPIStartingPoint(PIHandlerImpl.java:348)
at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:284)
at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:184)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:186)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
at com.sun.corba.ee.impl.presentation.rmi.bcel.BCELStubBase.invoke(BCELStubBase.java:225)
Is there anything I can do here to preserve information about the actual cause of the problem?
The cause of the problem should be available in the server log of the domains hosting the EJB that had a problem.
It sounds like getting more info back from the other end may be difficult... I do not know which issue tracker would be the right one for the info lost when the ApplicationException is created/thrown.
A total hack would be to create a set of custom exception classes in the project that has the ejb that has failed. You would make them very fine grained to cover the likely causes of the problem and provide enough detail in their name to identify the actual location of the problem, too. Yucky... but that may be the only choice until an issue gets filed and the fix is distributed.
Is there anything I can do here to
preserve information about the actual
cause of the problem?
Unfortunately, no. The ORB does not use normal object serialization for system exceptions (i.e., org.omg.CORBA.*), which means that causes are lost. As #vkraemer said, you'll need to rely on server logs.
I finally got to the bottom of this: actually, Glassfish transmits exceptions through IIOP quite correctly and everything works as it should... unless you do something idiotic like this:
try{
ejb.getFoo();
}catch (Exception e){
// try again
ejb.getFoo();
}
Yeah, it was our own damn code that swallowed the exception and tried to call a transaction-requiring EJB method within a distributed transaction that's been rolled back due to the exception.
What is the reason for encountering this Exception:
Error commiting responsejava.io.IOException: Broken pipe at sun.nio.ch.FileDispatcher.write0(Native Method)
I encounter this exception when i do a page redirect from http to https.
And the strange thing is that i can access https in the first 10 to 20 requests.
But subsequent requests that i encounter this broken pipe issue
Below is the full exception
Error commiting responsejava.io.IOException: Broken pipe at sun.nio.ch.FileDispatcher.write0(Native Method) at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:29) at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:104) at sun.nio.ch.IOUtil.write(IOUtil.java:75) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:302) at com.sun.enterprise.server.ss.ASOutputStream.write(ASOutputStream.java:120) at com.sun.net.ssl.internal.ssl.OutputRecord.writeBuffer(OutputRecord.java:283) at com.sun.net.ssl.internal.ssl.OutputRecord.write(OutputRecord.java:272) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:666) at com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:59) at org.apache.coyote.http11.InternalOutputBuffer.commit(InternalOutputBuffer.java:602) at com.sun.enterprise.web.connector.grizzly.ProcessorTask.action(ProcessorTask.java:721) at org.apache.coyote.Response.action(Response.java:188) at org.apache.coyote.Response.sendHeaders(Response.java:380) at org.apache.coyote.tomcat5.OutputBuffer.doFlush(OutputBuffer.java:357) at org.apache.coyote.tomcat5.OutputBuffer.close(OutputBuffer.java:318) at org.apache.coyote.tomcat5.CoyoteResponse.finishResponse(CoyoteResponse.java:528) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:192) at com.sun.enterprise.web.connector.grizzly.ProcessorTask.doProcess(ProcessorTask.java:604) at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:475) at com.sun.enterprise.web.connector.grizzly.ProcessorTask.doTask(ProcessorTask.java:426) at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:281) at com.sun.enterprise.web.connector.grizzly.WorkerThread.run(WorkerThread.java:83
Broken pipe usually means that the other side closed or aborted the pipe.
Because something didn't work.
If you'd like a more detailed answer, try editing your question and providing some context (like, what you were doing when it happened, what your code looks like, etc.).
Otherwise, that's about the best answer anyone is going to be able to give you unless they happen by pure chance to know what you're talking about.