A number of older plugins use $Response = new Response() instead of what the current plugin documentation shows: $Response = new TwimlResponse;
I created a plugin using openvbx version 1.2, but when pushing to production, version .9, it looks like it doesn't recognize TwimlResponse as a method.
I replaced TwimlResponse with Response, but it looks like .9 doesn't recognize $_REQUEST['From']. Does anyone know what the method for pulling the call from number was in .9?
Are there any concerns with upgrading our production OpenVBX instance?
It's not a question of OpenVBX per se but instead the Twilio PHP library behind the scenes. As you've seen, there were a number of updates of the library between those OpenVBX releases which are giving you stress now.
My recommendation is to backup your 0.9 install and do a test upgrade to 1.2.x and if everything works as expected do the real upgrade.
Related
We are currently upgrading PHP form 7.1 to PHP 8.2 for a legacy application which uses Apache, FriendsOfSymfony 1.5.15, ExtJs 3.4 and ExtDirect.
The following problem occurs: Sending a request to the Symfony backend creates the result as expected. The ExtDirect plugin, dsExtDirectPlugin, handles the request and response until a certain point in the dsExtDirectRouter.class.php where the code echos the response from the Symfony endpoint:
echo json_encode(self::$response);
From this point on Symfony shutdowns down logging,... and I expect that the response echod is used in JavaScript from that point on, but in the Firefox development tools, I see "no data available" in the network tab. So the output doesn't seem to come to the frontend / is suppressed from being echod?
Does anyone have a clue what can cause this? Do I need an additional php or apache config?
Thanks and kind regards,
Dirk
I found the solution for my prolbem: fastcgi_finish_request seems to be executed too early. Probably there's still some kind of misconfiguration on the Apache / PHP. If I directly add the fastcgi_finish_request call after the result "echo" and comment out the method call in the sfWebResponse (cached) class, it works. Of course not the final solution to comment something out in a commented class, but at least knowing the problem is a first step to the final solution.
Following the ODATA V4 tutorial in step 2: app runs against mockserver, tips are given to run it against a real server. Used the existing index.html as test/mockServer.html and created a new index.html, pointing to ComponentSupport for oninit. Added cors-anywhere and adjusted the manifest. Works well, both mockserver and real.
That was in step 2 and the app worked fine also against a real server. Fast-forward to step 5 and I notice the app fails to load any data when running against a real server. Long story short, the backend is throwing an error, not even "count" together with "top" is accepted. I checked the docs for ODATA, "count" does not seem to be an exclusive option.
Am I fundamentally misunderstanding the way ODATA works? I am especially puzzled by the fact that the mockserver runs fine.
EDIT: created bugreport
As reported in the closing comment of my bugreport, Microsoft has confirmed the issue: "This was due to an error in the version of the OData WebAPI library we were using in the backing service. I have an update with various fixes, including updating to the latest WebAPI library that contains this fix, that I just haven't pushed out to production yet. Let me see when if I can get that deployed."
I'm using Hangfire in my MVC webapp. I configured it this way:
GlobalConfiguration.Configuration
.UseMongoStorage(mongoConnectionString, mongoDatabaseName);
app.UseHangfireServer();
When I run the application I see IIS Worker Process takes constantly almost 40% CPU.
Removing it brings the application to works normally.
What's wrong?
Hangfire.Mongo since version 0.2.2 uses a new version of the mongocsharpdriver package that migrated to async API when talking with Mongo. Hangfire still uses synchronous methods, and looks like there is an error in "sync over async" wrapper.
One user reported that after setting the following options everything is fine.
CountersAggregateInterval = TimeSpan.FromMinutes(5);
JobExpirationCheckInterval = TimeSpan.FromHours(1);
However, the fix isn't available currently, and another option is to downgrade the Hangfire.Mongo package to the previous version. Please see the related GitHub issue.
I think my issue is somehow related to the issue described in the post https://stackoverflow.com/questions/12526125/monodroid-wcf-request-response-of-2-asynch-requests-got-mixed. If it is so, the question is when it's going to be fixed. The MonoDroid 4.2.6 seems still having the issue.
My exact problem is this. In the main action I start 5 async service requests. 4 service requests to one service and 1 service request to another service. Before sending the requests I add [ServiceName]Completed event listeners. The event listener for the service with one call is fired and two of the other event listeners are fired but they are fired twice. First time with the .Result equal null and the second time with the valid .Result object. The other two event listeners are never fired. On the service side I correctly receive all 5 requests and the service sends back all the responses.
It is rather difficult to isolate the problem. Two many things were changed in the environment. The last version that worked was running on the Windows 7, using MonoDroid 4.2.4 and VS2010 was used for compiling the project.
Now the problem is revealed under Windows 8, using MonoDroid 4.2.6 and VS2012 was used for compiling the project.
It does sound like this is a bug pure and simple in the Mono code.
Looking at https://bugzilla.xamarin.com/show_bug.cgi?id=7200 it claims this is now available in 6.0.2 in the Beta channel.
If you are still seeing the original problem, then contact Xamarin via Bugzilla - and via support#xamarin.com too if needed - it looks like they are keen to resolve the issue.
Please try Mono for Android 4.2.7, which has a number of related bug fixes.
We have been having an issue for months now and I cannot find a possible solution.
We have a server X that hosts a webapp. This webapp, among other things, deals with a svn repository hosted in server Y. This server (repository) is reached using WeBDAV through http://Y/svn/repository
The issue is that sometimes and totally random I get following error when trying to create a new folder in the repository or commit a file (it fails basically in operations that require to commit something):
Svn::Error::RaDavRequestFailed: Server sent unexpected return value (409 Conflict) in response to MKACTIVITY request for '/svn/repository/certainPath';
There is another service S that makes requests to the webapp and causes the svn operations and I can tell that this service uses multiple threads (which I believe is somehow causing the problem but not sure about that).
I have searched all over the place but didn't really find anything useful. I know from another friend that they have that issue too and upgrading to svn 1.7 fixed the issue. In my case upgrading to a newer version is not that simple so I prefer to fix the issue and, of course, finally understand what the hell is going on!
Thanks!
Details:
Server X and Y have Snow Leopard
svn version in X is 1.6.17 (r1128011)
apache version in Y I don't know (no access)