when creating new theme there's error occurred.
0 - Communication Failure
Why this happen? could you please help me?
This usually happens due to a timeout that occurs when the Theme-controller tries to read the Theme's configuration for the first time. Unfortunately, this is quite a resource-heavy process; on weaker servers, timeouts may occur during this process quite often.
You can confirm this by opening the Theme-Manager, opening your browser's developer tools, refreshing the Theme overview and look at the response of the backend/Themes/list-Request.
You can give your server more time with the php-function set_time_limit. In engine/Shopware/Components/Theme/Installer.php, in the synchronize-method, prepend set_time_limit(0):
public function synchronize()
{
set_time_limit(0);
$this->synchronizeThemes();
}
Alternatively, prepend set_time_limit(0); to your shopware.php file, but don't forget to remove it again once the theme-overview loaded successfully.
Helllo,
My application is a web server that fires many requests to other servers. We set up a maximum timeout on those requests, and whenever the timeout is reached, the connection is closed and a ESOCKETTIMEDOUT rises.
Error: socket hang up
at createHangUpError (http.js:1472:15)
at Socket.socketCloseListener (http.js:1522:23)
at Socket.EventEmitter.emit (events.js:117:20)
at TCP.close (net.js:465:12)
I want to exclude these errors from the New Relic Dashboard, since they distort the error rate and other metrics. Hiding them doesn't work either, because they still count in the error rate.
How can remove specific errors (that do not have a HTTP status code) from my Dashboard?
You can pass status codes to ignore to the error collector. If you are configuring the New Relic agent using environment variables you can use a comma separated list of codes as the value for NEW_RELIC_ERROR_COLLECTOR_IGNORE_ERROR_CODES.
See the README.
If you are using newrelic.js to do so you can set the error_collector.ignore_codes value to an Array of status codes to ignore:
See the example config.
Important caveat: when setting this value manually you are overriding the default value of 404 which means that if you do not specify 404 in your manual configuration the Error Collector will start logging all 404 errors in your application (which you probably do not want).
I noticed you have javascript, I'm not sure if my solution can help you but I'll answer in the hope it does.
I use Java agent, and we have the same kind of problem. So far the only way that I found that can do something near what I want is having the specific errors wrapped in a dedicated exception ("NewRelicIgnorableException") and wrap whatever error I don't want to see in it.
Then I'd have to go into the dashboard/application and select "error collection". Last, I'd fill in the "Ignore these errors" with the full package name AND exception class name, like com.mypackage.NewRelicIgnorableException. Save and enjoy. These particular errors should not impact your apdex, but they will still count towards RPM and other metrics.
Other solutions have drawbacks. For example if I call ignoreexception the RPM and time metrics will not count. If you click the "hide error" button you only hide them from the error panel, but everything else will be as usual. If you ignore by status code you can get more or less the same results as ignoring the specific exception, but without any hope for fine control.
It's a pity that there's so little documentation on their site, I had to run tests to find these out.
I am trying to implement Paul Calhoun's Apache FOP solution for creating PDF's from Xpages (from Notes In 9 #102). I am getting the following java exception when trying to run the xAgent that does the processing --> Can't get a Writer while an OutputStream is already in use
The only changes that I have done from Paul's code was to change the package name. I have isolated when the exception happens to the SSJS line: var jce: DominoXMLFO2PDF = new DominoXMLFO2PDF(); All that line does is instantiate the class, there is no custom constructor. I don't believe it is the code itself, but some configuration issue. The SSJS code is in the beforeRenderResponse event where it should be, I haven't changed anything on the xAgent.
I have copied the jar files from Paul's sample database to mine, I have verified that the build paths are the same between the two databases. Everything compiles fine (after I did all this.) This exception appears to be an xpages only exception.
Here's what's really going on with this error:
XPages are essentially servlets... everything that happens in an XPage is just layers on top of a servlet engine. There are basically two types of data that a servlet can send back to whatever is initiating the connection (e.g. a browser): text and binary.
An ordinary XPage sends text -- specifically, HTML. Some xAgents also send text, such as JSON or XML. In any of these scenarios, however, Domino uses a Java Writer to send the response content, because Writers are optimized for sending Character data.
When we need to send binary content, we use an OutputStream instead, because streams are optimized for sending generic byte data. So if we're sending PDF, DOC/XLS/PPT, images, etc., we need to use a stream, because we're sending binary data, not text.
The catch (as you'll soon see, that's a pun) is that we can only use one per response.
Once any HTTP client is told what the content type of a response is, it makes assumptions about how to process that content. So if you tell it to expect application/pdf, it's expecting to only receive binary data. Conversely, if you tell it to expect application/json, it's expecting to only receive character data. If the response includes any data that doesn't match the promised content type, that nearly always invalidates the entire response.
So Domino in its infinite wisdom protects us from making this mistake by only allowing us to send one or the other in a single request, and throws an exception if we disobey that rule.
Unfortunately... if there's any exception in our code when we're trying to send binary content, Domino wants to report that to the consumer... which tries to invoke the output writer to send HTML reporting that something went wrong. Except we already got a handle on the output stream, so Domino isn't allowed to get a handle on the output writer, because that would violate its own rule against only using one per response. This, in turn, throws the exception you reported, masking the exception that actually caused the problem (in your case, probably a ClassNotFoundException).
So how do we make sure that we see the real problem, and not this misdirection? We try:
try {
/*
* Move all your existing code here...
*/
} catch (e) {
print("Error generating dynamic PDF: " + e.toString());
} finally {
facesContext.responseComplete();
}
There are two reasons this is a preferred approach:
If something goes wrong with our code, we don't let Domino throw an exception about it. Instead, we log it (instead of using print to send it to the console and log, you could also toss it to OpenLog, or whatever your preferred logging mechanism happens to be). This means that Domino doesn't try to report the error to the user, because we've promised that we already reported it to ourselves.
By moving the crucial facesContext.responseComplete() call (which is what ultimately tells Domino not to send any content of its own) to the finally block, this ensures it will get executed. If we left it inside the try block, it would get skipped if an exception occurs, because we'd skip straight to the catch... so even though Domino isn't reporting our exception because we caught it, it still tries to invoke the response writer because we didn't tell it not to.
If you follow the above pattern, and something's wrong with your code, then the browser will receive an incomplete or corrupt file, but the log will tell you what went wrong, rather than reporting an error that has nothing to do with the root cause of the problem.
I almost deleted this question, but decided to answer it myself since there is very little out on google when you search for the exception.
The issue was in the xAgent, there is a line importPackage that was incorrect. Fixing this made everything work. The exception verbage: "Can't get a Writer while an OutputStream is already in use" is quite misleading. I don't know what else triggers this exception, but an alternative description would be "Java class ??yourClass?? not found"
If you found this question, then you likely have the same issue. I would ignore what the exception actually says, and check your package statements throughout your application. The java code will error on its own, but your SSJS that references the java will not error until runtime, focus on that code.
Update the response header after the body can solve this kind of problem, example :
HttpServletResponse response = (HttpServletResponse) facesContext.getExternalContext().getResponse();
response.getWriter().write("<html><body>...</body></html>");
response.setContentType("text/html");
response.setHeader("Cache-Control", "no-cache");
response.setCharacterEncoding("UTF-8");
I'm experimenting with Dart and using the new streamSpawnFunction to create a new isolate.
I'm running my code in Dartium but i've noticed that if some kind of unrecoverable error occurs in the isolate i get no error message on the console. Because breakpoints in Isolate code are not working debugging is really painful.
The old Port based Isolate spawn function (spawnFunction) has a callback function for handling errors. I wonder why this is not available with streamSpawnFunction. Is there a new way to subscribe to the error events of an Isolate?
The missing functionality of streamSpawnFunction is just an oversight. I filed http://dartbug.com/9208 and I will try to fix it next week.
I'm not sure if it is a known problem that breakpoints don't work in isolates. I will let you file a bug-report (http://dartbug.com) so the devs can ask you questions and you are kept informed on the process.
We have one very old legacy application written on Classic ASP. Recently on a couple of servers we've started to get fatal errors. IIS process crashes. We've got few error's stack traces with IIS Debug Tool. There is 2 common types of errors.
We are using only few types of COM components in our application: ADO, Scripting.Dictionary, Scripting.FileSystem & MSXML6.
IIS logs says that error description is access violation exception (0xC0000005).
Do you have any ideas about the reason of errors or any ways for future debugging. Any ways to get more info about this errors will be very appreciated.
Thanks.
Stack traces:
1.
1996e18
oleaut32!VariantCopy+173
oleaut32!SafeArrayCopyData+14e
oleaut32!SafeArrayCopy+e3
oleaut32!VariantCopy+5b
oleaut32!VariantCopyInd+1a1
asp!CComponentObject::GetVariant+27
asp!CApplnVariants::get_Item+da
oleaut32!DispCallFunc+16a
oleaut32!CTypeInfo2::Invoke+234
asp!CDispatchImpl<IVariantDictionary>::Invoke+55
oleaut32!CTypeInfo2::Invoke+58a
asp!CDispatchImpl<IApplicationObject>::Invoke+55
vbscript!IDispatchInvoke2+b2
vbscript!IDispatchInvoke+59
vbscript!InvokeDispatch+13a
vbscript!InvokeByName+42
vbscript!CScriptRuntime::RunNoEH+22b2
vbscript!CScriptRuntime::Run+62
vbscript!CScriptEntryPoint::Call+51
vbscript!CSession::Execute+c8
vbscript!COleScript::ExecutePendingScripts+144
vbscript!COleScript::SetScriptState+14d
asp!CActiveScriptEngine::TryCall+19
asp!CActiveScriptEngine::Call+31
asp!CallScriptFunctionOfEngine+5b
asp!ExecuteRequest+17e
asp!Execute+24c
asp!CHitObj::ExecuteChildRequest+12c
asp!CErrInfo::LogCustomErrortoBrowser+28a
asp!CErrInfo::LogErrortoBrowserWrapper+8b
asp!CErrInfo::LogError+77
asp!HandleError+100
asp!HandleErrorMissingFilename+ac
asp!CActiveScriptEngine::Call+a7
asp!CallScriptFunctionOfEngine+5b
asp!ExecuteRequest+17e
asp!Execute+24c
asp!CHitObj::ViperAsyncCallback+3f0
asp!CViperAsyncRequest::OnCall+92
comsvcs!CSTAActivityWork::STAActivityWorkHelper+32
ole32!EnterForCallback+c4
ole32!SwitchForCallback+1a3
ole32!PerformCallback+54
ole32!CObjectContext::InternalContextCallback+159
ole32!CObjectContext::DoCallback+1c
comsvcs!CSTAActivityWork::DoWork+12d
comsvcs!CSTAThread::DoWork+18
comsvcs!CSTAThread::ProcessQueueWork+37
comsvcs!CSTAThread::WorkerLoop+190
msvcrt!_endthreadex+a3
kernel32!BaseThreadStart+34
2.
scrrun!FreeList+f
scrrun!VBADictionary::~VBADictionary+28
scrrun!VBADictionary::`scalar deleting destructor'+d
scrrun!VBADictionary::Release+17
oleaut32!VariantClear+b1
oleaut32!ReleaseResources+98
oleaut32!_SafeArrayDestroyData+4d
oleaut32!_SafeArrayDestroy+b3
oleaut32!SafeArrayDestroy+f
oleaut32!VariantClear+75
vbscript!VAR::Clear+a6
vbscript!CScriptRuntime::Cleanup+63
vbscript!CScriptRuntime::Run+8d
vbscript!CScriptEntryPoint::Call+51
vbscript!CScriptRuntime::RunNoEH+1e02
vbscript!CScriptRuntime::Run+62
vbscript!CScriptEntryPoint::Call+51
vbscript!CScriptRuntime::RunNoEH+1e02
vbscript!CScriptRuntime::Run+62
vbscript!CScriptEntryPoint::Call+51
vbscript!CScriptRuntime::RunNoEH+1e02
vbscript!CScriptRuntime::Run+62
vbscript!CScriptEntryPoint::Call+51
vbscript!CScriptRuntime::RunNoEH+1e02
vbscript!CScriptRuntime::Run+62
vbscript!CScriptEntryPoint::Call+51
vbscript!CSession::Execute+c8
vbscript!COleScript::ExecutePendingScripts+144
vbscript!COleScript::SetScriptState+14d
asp!CActiveScriptEngine::TryCall+19
asp!CActiveScriptEngine::Call+31
asp!CallScriptFunctionOfEngine+5b
asp!ExecuteRequest+17e
asp!Execute+24c
asp!CHitObj::ViperAsyncCallback+3f0
asp!CViperAsyncRequest::OnCall+92
comsvcs!CSTAActivityWork::STAActivityWorkHelper+32
ole32!EnterForCallback+c4
ole32!SwitchForCallback+1a3
ole32!PerformCallback+54
ole32!CObjectContext::InternalContextCallback+159
ole32!CObjectContext::DoCallback+1c
comsvcs!CSTAActivityWork::DoWork+12d
comsvcs!CSTAThread::DoWork+18
comsvcs!CSTAThread::ProcessQueueWork+37
comsvcs!CSTAThread::WorkerLoop+190
msvcrt!_endthreadex+a3
kernel32!BaseThreadStart+34
We had very similar situation last couple weeks. It was very complicated to track down this issue. The problem is in OnError handler of VB6 code. There are 2 cases to reproduce:
you do not have OnError handler, error occurs and goes directly to
IIS
error occurs in OnError handler and goes directly to IIS.
After ~100 such errors IIS will fail to work normally. It will be absolutely unpredictable behavior after this moment.