I recently encountered a strange thing. On some of my company's servers when an exception message is printed out (yes, bad, I know. It's for debugging), the actual message isn't displayed. Instead it displays the key for an external string resource and says that "Debugging resource strings are unavailable"
After some research I've come up with the following:
In release mode, Silverlight does not package the xap with the dlls containing the actual error messages in order to save space.
I've found workarounds for OLD versions, but nothing for 4. It seems like there are Developer versions of the SL 2 and 3 runtime which will resolve the errors automatically, but I cannot find one for SL 4.
So my question is this:
What the heck do I need to do to my SL 4 app / computer to let me see the full, detailed errors when it's in release mode?
You can download the developer runtime (which contains the full exception strings) from the GetStarted page - http://www.silverlight.net/getstarted/ - search for "Developer Runtimes for Windows and OSX", it's near the bottom of the page.
Though it is too late to reply, it may help somebody else. We have a web application using Silverlight 4, installed in various test environments. This web application consumes more than one WCF services. All but one of the test environment sites consistently failed with message "Debugging Resource strings are unavailable". Agreeably the real exception was swallowed. Being a Silverlight application, there was no logging, and it always appeared that there was something failing in the Silverlight component. I connected the application in my development environment to that particular test environment, and found out that the problem was in fact in one of the WCF services. I fixed the problem at the service end and the SL component stopped having this problem.
Why was the WCF failing?
The WCF service had the following code in the constructor:
public MyService()
{
//Create an instance of Data Lookup service asycnchronously.
if (_dataLookupSrvc == null)
{
try
{
System.Threading.Tasks.Task.Factory.StartNew(() => _dataLookupSrvc = new LookupDataService.LookupDataService());
}
catch (Exception ex)
{
_log.Error<Exception>(ex);
}
}
}
Somebody moved the underlying LookupDataService.dll from the service folder causing the constructor to fail, but not right away. As the LookupDataService instance was created in anonymous method, the exception logging in this method never took place. Once the LookupDataService.dll was dropped in the service folder, the "Debugging Resource strings are unavailable" message went away.
It was a fun wild goose chase!
Have you already checked the event viewer on the machine where the application crashed? Start->Run. eventvwr
Related
I am doing a lookup operation Couchbase Java SDK 3.0.9 which looks like this:
// Set up
bucket = cluster.bucket("my_bucket")
collection = bucket.defaultCollection()
// Look up operation
val specs = listOf(LookupInSpecStandard.get("hash"))
collection.lookupIn(id, specs)
The error I get is BUCKET_NOT_AVAILABLE. Here are is the full message:
com.couchbase.client.core.error.UnambiguousTimeoutException: SubdocGetRequest, Reason: TIMEOUT {"cancelled":true,"completed":true,"coreId":"0xdb7f8e4800000003","idempotent":true,"reason":"TIMEOUT","requestId":608806,"requestType":"SubdocGetRequest","retried":39,"retryReasons":["BUCKET_NOT_AVAILABLE"],"service":{"bucket":"export","collection":"_default","documentId":"export:main","opaque":"0xcfefb","scope":"_default","type":"kv"},"timeoutMs":15000,"timings":{"totalMicros":15008977}}
The strange part is that this code hasn't been touched for months and the lookup broke out of a sudden. The CB cluster is working fine. Its version is
Enterprise Edition 6.5.1 build 6299.
Do you have any ideas what might have gone wrong?
Note that in Couchbase Java SDK 3.x, the Cluster::bucket method returns instantly, and continues opening a bucket in the background. So the first operation you perform - a lookupIn here - needs to wait for that resource opening to complete before it can proceed. It looks like it took a little longer to access the Couchbase bucket than usual and you got a timeout.
I recommend using the Bucket::waitUntilReady method after opening a bucket, to block until the resource opening is complete:
bucket = cluster.bucket("my_bucket")
bucket.waitUntilReady(Duration.ofMinutes(1));
This problem can occur because of firewall. You need to allow these ports.
Client-to-node
Unencrypted: 8091-8097, 9140 [3], 11210
Encrypted: 11207, 18091-18095, 18096, 18097
You can check more from below
https://docs.couchbase.com/server/current/install/install-ports.html#_footnotedef_2
I have a PWA built with Angular 6 and the #angular/pwa npm package and authenticating using adal-angular4 npm package (but could just rebuild that from scratch if needed -- the issue isn't a bug in the package I think)
When attempting to authenticate, although it does work, users are very often greeted with this message of not found (screenshot of console but its the same).
This especially seems to be the case if you are already authenticated to another (or itself) Azure AD product. Where it normally should only load for a while and then let the user in.
Service worker error transcript:
Failed to load 'link.com/#LONGTOKEN' A serviceWorker passed a promise
to FetchEvent.respondWith() that rejected with 'Error: Response not Ok
(fetchAndCacheOnce): request for LINK.com/index.html returned response 404 Not Found'.
It seems that writing a function to check for new version of the PWA has cleaned up everything. Because it's a PWA, when replacing files with a new version -- the cache will still be there and shift+reloading won't necessarily clear it, causing a lot of unwanted behaviour.
The code for the cleanup looks like this:
First, inject in the constructor the following: updates: SwUpdate
import { SwUpdate } from "#angular/service-worker"
Then, inside ngOnInit, I have the following:
updates.available.subscribe(event => {
updates.activateUpdate().then(() => document.location.reload());
})
It will force a complete refresh 2-3 seconds in if there's a new version available but all works well afterwards.
I was wondering if Wirecloud offers complete support for object storage with FI-WARE Testbed instead of Fi-lab. I have successfully integrated Wirecloud with Testbed and have developed a set of widgets that are able to upload/download files to specific containers in Fi-lab with success. However, the same widgets do not seem to work in Fi-lab, as i get an error 500 when trying to retrieve the auth tokens (also with the well known object-storage-test widget) containing the following response:
SyntaxError: Unexpected token
at Object.parse (native)
at create (/home/fiware/fi-ware-keystone-proxy/controllers/Token.js:343:25)
at callbacks (/home/fiware/fi-ware-keystone-proxy/node_modules/express/lib/router/index.js:164:37)
at param (/home/fiware/fi-ware-keystone-proxy/node_modules/express/lib/router/index.js:138:11)
at pass (/home/fiware/fi-ware-keystone-proxy/node_modules/express/lib/router/index.js:145:5)
at Router._dispatch (/home/fiware/fi-ware-keystone-proxy/node_modules/express/lib/router/index.js:173:5)
at Object.router (/home/fiware/fi-ware-keystone-proxy/node_modules/express/lib/router/index.js:33:10)
at next (/home/fiware/fi-ware-keystone-proxy/node_modules/express/node_modules/connect/lib/proto.js:195:15)
at Object.handle (/home/fiware/fi-ware-keystone-proxy/server.js:31:5)
at next (/home/fiware/fi-ware-keystone-proxy/node_modules/express/node_modules/connect/lib/proto.js:195:15)
I noticed that the token provided in the beggining (to start the transaction) is
token: Object
id: "%fiware_token%"
Any idea regarding what might have gone wrong?
The WireCloud instance available at FI-WARE's testbed is always the latest stable version while the FI-LAB instance is currently outdated, we're working on updating it as soon as possible. One of the things that changes between those versions is the Object Storage API, so sorry for the inconvenience as you will not be able to use widgets/operators using the Object Storage in both environments.
Anyway, the response you were obtaining seems to indicate the object storage instance you are accessing is not working properly, so you will need to send an email to one of the available mail lists for getting help (fiware-testbed-help or fiware-lab-help) telling what is happening to you (remember to include your account information as there are several object storage nodes and ones can be up and the others down).
Regarding the strange request body:
"token": {
id: "%fiware_token%"
}
This behaviour is normal, as the WireCloud client code has no direct access to the IdM token of the user. It's the WireCloud's proxy which replaces the %fiware_token% pattern with the correct value.
I'm trying to debug an issue on a clients machine. The problem is that the problem is a runtime error with very little clue as to where it is. It is an intermittent problem. I know ADL allows me to run the application in a debug mode. The problem is that to tell the user to download and manage the ADL invokation is going to be very difficult. It would be a lot easier if I could just give the end user one install/executable to install and run and then send me the trace of the issue. So what I'm looking for is easy steps for the client to be able to run the AIR app in debug mode. Downloading ADL and finding the install location of the app is going to be difficult to manage remotely with the end user.
Update:
You have to make sure you are working with AIR 3.5 and Flash 11.5 and also include the following flag "-swf-version=18" in additional compiler settings. You then have to catch the global error as mentioned in the answer and it will show you the location of the error. No line numbers of course. Just routine names. Thanks a milion to Lee for the awsome answer.
not a direct answer but if you publish for AIR3.5 (or 3.6 beta), you can get some debug info:
add a listener for uncaught RTEs to top level of your app:
this.loaderInfo.uncaughtErrorEvents.addEventListener(UncaughtErrorEvent.UNCAUGHT_ERROR, globalErrorHandler);
and grab debug info from error in listener:
function globalErrorHandler(event:UncaughtErrorEvent):void
{
var message:String;
//check for runtime error
if (event.error is Error)
message = (event.error as Error).getStackTrace();
//handle other errors
else if (event.error is ErrorEvent)
message = (event.error as ErrorEvent).text;
else
message = event.error.toString();
//do something with message (eg display it in textfield)
myTextfield.text = message;
}
getStackTrace will return a stack trace even for release AIR apps (as long as you use AIR3.5 or above).
Without the SDK Tools; I don't think it is possible to run an aIR app in debug mode. But, here are a few alternatives to consider:
The client must have some idea what is going on to cause the error, right? Can you give them a special build with Alert Boxes or logging or something to help isolate the error to a line of code?
Can you listen for the uncaughtException event? The event will give you the full stack trace ( Error.getStackTrace() ); which you could then log--possibly with other information. Then you just have to tell your client to "Go here" and "send me this file." Or even display the info in some Alert and have the user copy and paste it into an email to you. More info on uncaughtException here and here
check my post. Maybe it helps you to get stack trace with line numbers in a AIR release build.
How can I get stacktrace for Adobe AIR global runtime errors in non-debug mode?
I use it in 2 big projects right now and it works very well.
Greetings
I am at a complete loss as to why I am experiencing this problem. I am new to NServiceBus and have so far set up a dead simple 'server' which listens for messages sent by a web application. The server asks for custom initialisation (IWantCustomInitialization) and uses a custom builder for Castle Windsor 2.5.1. This custom builder is basically a copy of the one that comes with the NServiceBus source code, with two minor changes to move away from methods deprecated in Windsor 2.5.
Note that my code shares the container instance with NServiceBus.
The problem I experience is that every message sent by the web application is processed five (5) times by the server. The log files have five entries for each attempt, with the fifth attempt looking like this:
2011-03-28 16:04:10,326 [Worker.8] DEBUG NServiceBus.Unicast.UnicastBus [] - Calling 'HandleEndMessage' on NServiceBus.SagaPersisters.NHibernate.NHibernateMessageModule
2011-03-28 16:04:10,327 [Worker.8] DEBUG NServiceBus.Unicast.UnicastBus [] - Calling 'HandleEndMessage' on Server.NHibernateSessionMessageModule
2011-03-28 16:04:10,341 [Worker.8] DEBUG NServiceBus.Unicast.UnicastBus [] - Calling 'HandleError' on NServiceBus.SagaPersisters.NHibernate.NHibernateMessageModule
2011-03-28 16:04:10,342 [Worker.8] DEBUG NServiceBus.Unicast.UnicastBus [] - Calling 'HandleError' on Server.NHibernateSessionMessageModule
2011-03-28 16:04:10,344 [Worker.8] ERROR NServiceBus.Unicast.Transport.Msmq.MsmqTransport [] - Message has failed the maximum number of times allowed, ID=80cffd98-a5bd-43e0-a482-a2d96ca42b22\20677.
I have no indication why the message fails, and I don't know where to dig for more information/output.
The configuration 'endpoint' looks like this:
public void Init()
{
container = Windsor.Container;
NServiceBus.Configure.With().CastleWindsor251Builder(container).XmlSerializer().MsmqTransport().IsolationLevel(System.Transactions.IsolationLevel.Unspecified);
var masterInstaller = new NotificationServerInstaller();
masterInstaller.Install(container, null);
}
The message handler is, at this stage, really contrived, and looks like this:
public class NewUserMessageHandler : IHandleMessages<NotifyNewUserMessage>
{
private readonly IGetUserQuery _getUserQuery;
public NewUserMessageHandler(IGetUserQuery getUserQuery)
{
_getUserQuery = getUserQuery;
}
public void Handle(NotifyNewUserMessage message)
{
var result = _getUserQuery.Invoke(new GetUserRequest { Id = new Guid("C10D0684-D25F-4E5E-A347-16F85DB7BFBF") });
Console.WriteLine("New message received: {0}", message.UserSystemId);
}
}
If the first line in the handler method is commented out, the message is processed only once.
I have found some posts/threads on the web (including StackOverflow) which talk about similar issues, notably http://tech.groups.yahoo.com/group/nservicebus/message/5977 and Anyone using Ninject 2.0 as the nServiceBus ObjectBuilder? - but I haven't had any success in making my problem go away.
I'd be most obliged for any help. I'm a n00b at NServiceBus!
NServiceBus isn't handling it multiple times by default it will retry 5 times if an exception occurs, you can set this in a config file. Have you got distributed transactions turned on? Because you are committing to a database and you have an open transaction (the queue transaction) when you open another transaction it will try and upgrade it to a distributed transaction, I think that may be the issue. Have you run with the console app? You should see some out put on there.
I would recommend wrapping the body of the Handle method in a try/catch and add a break point to the catch and see what is wrong.
Once you work it out, remove the try/catch.