We have a problem that happens sometimes without any pattern we are able to see.
We log a request just before a callout, it looks fine, with data in the body. When the request arrives at the service we are calling the body is empty.
We restarted the development machine, did not help.
We then add a tunnel to see what is being sent out it starts working. Take the tunnel away and it still works.
Next day it stops working again, we put the tunnel back and it still does not work.
Anyone any idea what could be causing this?
This appears to have been a dependency that we had included, but did not use. When we removed the dependency and republished it started working again.
We think that the contents in this dependency generated a namespace conflict, but this only shows up when some other part of the system has loaded these files.
Related
While running the code with displacy, I see the images being created perfectly as expected.
They are also projected to a server, the address of which is mentioned every time someone runs the code. But the problem I am facing is that the code doesn't stop & maybe keeps on running to maintain the server.
Is there a way to put a timer to that?
No, there is no timer option. If you don't want the server you can just not call displacy.serve, and instead call displacy.render, which just returns the HTML.
See the displacy API docs for full details.
I am working on a website on my localhost and suddenly I'm now getting this errors.
I get this error on Firefox
<script> source URI is not allowed in this document
And nothing on chrome,` but if I try using the files code, I get:
Application Error: There was a problem getting data for the application you requested. The application may not be valid, or there may be a temporary glitch. Please try again later.
It is basically for: https://connect.facebook.net/en_US/sdk.js.
The browser doesn't even send a GET request for the file.
Everything used to work perfect before. Not sure why I'm getting this.
I had an extension installed on both of my browsers. It was preventing it from loading.
If you have any VPNs, hide-tracking extensions, then it needs to be disabled.
In my case it was Disconnect firefox/chrome extension.
Apologies Paul, this is a duplicate to the post I put on OpenNTF, however the site will not allow me to log in the last 2 days to follow up, plus the wider audience of Stack might find me someone with an identical issue.
To keep it short.
I have 1 openLog database in a folder structure, logs/xpageslog.nsf
During development, I could log to this database, for example, using Paul Withers XPages OpenLog Logger, to log uncaught exceptions with the following settings:
private String logDbName = "logs\\xpageslog.nsf"; // in OpenLogItem.java from OpenLogClass library
logDbName = "logs/xpages.nsf" // in OpenLogFunctions.ls
xsp.openlog.filepath=log/xpageslog.nsf // in xsp.properties
However, if I then change all the above, to simply go to xpageslog.nsf, in the root of the server (this is a 2nd openLog database) errors still get logged to the first database.
I've tried building, cleaning, re-compiling, all to no avail. It seem's to be that somewhere, or somehow, the references to the original database are not being overwritten.
Any ideas?
It is good practice to use restart task http instead of tell http restart. Both commands have different effects.
As confirmed in comments, this solved the problem.
Some use tell http quit followed by load http, the effect is the same as with restart task http. At the other hand, simple tell http restart does not fully initialize http task, it's kind of soft reset and I recommend not using it.
I have encountered a strange behaviour with express routes. I want to enter an ID via HTML-Form and fetch the result via ajav (jquery) to display the entry. All was working fine, till i have to expand the ID from numbers to strings (with slashes).
I edited all functions and calls. I check the strign with a reg ex and want to fetch the request with a modified route (express). but here comes the problem. i get it working under windows but it is failing on linux. Perhaps the problem is caused by the invrastructure, because the node.js app is located behind an reverse proxy apache2 to tunnel the service to public (with domain & cert).
what ever. perhaps somebody can help me set this thing up and get it running.
app.get(/^\/byId\/(.+)/, getSourceById);
not using req.params[0] in the called function. on the test server (windows) it is working even with the old route
app.get('/byId/:id', getSourceById);
because the html form does request %2F not /. How ever, both ways should work to fetch the request. But both aren't working for me. did i miss something?
i'm thankful for any help!
Found the answer of my question. It was indeed the reverse proxy who was blocking the request.
Simular problem: http://www.gossamer-threads.com/lists/apache/users/314562
How to solve the behaviour:
http://httpd.apache.org/docs/2.0/mod/core.html#allowencodedslashes
Default forbidden because of security issues. If you need it, use it carefully.
I'm using Play 2.1.2 and I'm having some trouble with an Enumerator and I'm seeking ideas on how to debug this.
I'm trying to stream some S3 data through my server. I can get an InputStream from the Amazon SDK for my S3 file (getObject(bucket, key).getObjectContent()). I then turn that InputStream into an Enumerator[Array[Byte]] using Enumerator.fromStream.
All this type checks and on my local development machine it all works perfectly. When I formulate my Result in Play, I just return Ok.stream(enum).
The problem comes when I deploy this to a production server. The very first time I request the file, it works just fine and I get the whole file. But subsequent times it frequently gets part way through (different amounts each time) and then gets "stuck". I wrapped the Enumerator as follows to be able to log whether the enumeration completed:
val wrapped = enum.onDoneEnumerating { println("Contents fully enumerated"); }
Ok.stream(wrapped);
As expected, on my development machine (and the first time through on the production machines), I get the message "Contents fully enumerated". But after that, the production machine will start the download of the file, but it doesn't finish (in both the HTTP sense and in the Enumerator sense).
I'm not sure how to debug this. Obviously, fromStream does some magic and I don't know how to figure out what is happening between chunks. I thought this might be a thread pool issue so I wrapped the whole response in a future { blocking { ... } } block, but it didn't appear to make any difference.
I'm trying to avoid the hassle of creating a local temporary file from S3 and then building my Enumerator from that. Using the fromStream to create an Enumerator seemed like the elegant way to do this...if it worked.
Suggestions?
OK, so I think I figured this out. It turns out that on the Play side, things appear to be working. I tried all kinds of variations (different ways of constructing the enumerator, creating temporary files, etc). It didn't really matter.
What did matter was the proxy I was using. I'm using node-http-proxy and if I make a request on the server behind the proxy, I get the correct response (directly from Play). If I make the request on the server outside the proxy, I get an incorrect (empty) response. So it looks like the proxy is "dropping" the response.
It appears the issue is that the response is chunked by the stream call and this is causing the problem with the proxy. If I reformulate my response to be:
SimpleResult( header = ResponseHeader(200), body = enum)
Then play uses the Enumerator to construct a complete response (not streamed) and things work again. Of course, it is stupid to have to form the complete response in this case, but it does work. Hopefully I can find a better solution than this in the long term, but this seems to work for now.