I have FusionReactor ENT v5 on my new server,
I have FusionReactor STD Edition v.5 on my old server.
The only problem I am having is that the WebRequest Runtime Protection is not working.
I have checked the settings,
http://docs.intergral.com/display/FR50/Protection+Settings
Request Runtime Protection Strategy
This defines what happens when this protection type is triggered. The individual survival strategies are defined as follows:
Abort (with Email Notification): Protection will attempt to abort any requests that have run for too long and have triggered Request Runtime Protection. Optionally sends an email notification containing details about the triggering request.
Email Notification Only: Send an email notification (as long as notification is enabled in FusionReactor Settings) but take no further action.
My reactor.conf from my old server:
fac.archive.retention.value=100
crashprotection.pagelist.0.track_stats=true
user.0=Administrator,administrator,XXXXXXXXXXXXXXXXXXXXXXXX,?p\=running&static\=&flavor\=WebRequest&__toc\=requests
crashprotection.pagelist.0.string=/directory1/directory2/SiteFile1.cfm
crashprotection.pagelist.1.string=directory1/directory2/SiteFile2.cfm
crashprotection.pagelist.count=2
crashprotection.email.address.to=TEST#domain.com
crashprotection.pagelist.1.scope=ALL
version=7
crashprotection.pagelist.0.scope=TIMEOUT
fruid=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
crashprotection.pagelist.1.track_stats=false
crashprotection.pagelist.1.regex=false
crashprotection.pagelist.0.regex=false
fac.archive.retention.strategy=SIZE
crashprotection.email.active=true
crashprotection.pagelist.0.append_parameters=false
crashprotection.requests.level.min=5
crashprotection.pagelist.1.prepend_hostname=false
crashprotection.pagelist.0.prepend_hostname=false
crashprotection.pagelist.1.append_parameters=false
fac.scheduler.mailjob.enable=true
crashprotection.email.server=127.0.0.1
crashprotection.request_timeout=60
crashprotection.email.address.from=fusionreactor#domain.com
gruid=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
My reactor.conf from my new server:
user.0=Administrator,administrator,XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
metrics.slow_threshold=2
crashprotection.email.active=true
crashprotection.email.server=127.0.0.1
crashprotection.request_timeout=10
email.hostname=local.domain.com
crashprotection.email.address.from=fusionreactor#domain.com
version=6
crashprotection.requests.level.min=5
metric.recent_slow_pages.statusthreshold.ok2w=1
crashprotection.email.address.to=testuser#omain.com
gruid=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
fruid=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The test email works fine and the crash notication email works fine.
The slow web request does not
By the looks of things your new server config looks ok for the CrashProtection settings. It might just be that the Protection system has not taken the settings correctly.
Have your tried restarting your server?
It looks like there is a bug in the current FR 5 agent where the Crash Protection settings would not correctly update if Quantity protection is enabled. A server restart should correct this issue.
If you do not wish to restart your server, you can try putting all the protection settings back to the defaults, save them. Then setting up Runtime protection first.
Hopefully this will solve your issue.
If you have any other problems I suggest you contact the FusionReactor support team at support#fusion-reactor.com.
Kind Regards,
Ben Donnelly
FusionReactor Support
Related
Trying to run Metaplex with locally hosted test validator. The wallet seems to be connecting correctly and showing the balance as expected. But it fails to initialize the store. Whenever I press "init store" I run into a timeout waiting for the transaction confirmation.
To enable connecting to localhost I've modified ENDPOINTS in 'connection.ts by adding the following to the array:
{
name: 'localnet' as ENV,
endpoint: 'http://127.0.0.1:8899',
ChainId: ChainId.Devnet,
}
Upon a closer investigation it seems that the init store does not actually deploy the programs to the local blockchain.
If by "Metaplex" in your orginal post you are referring to the Web UI here https://github.com/metaplex-foundation/metaplex/tree/master/js/packages/web keep in mind this UI does a lot of stuff.
As you have noted in your update: Metaplex is composed of many different program accounts. You would have to locate each of these accounts then "--clone" them on the solana-test-validator command line in order to ensure Metaplex works.
AFAIK there is no script or instructions about how to set up Metaplex from scratch.
The Metaplex storeFront is deprecated and is no longer maintained by the Metaplex Team. So i will advice for building an NFT Marketplace better use the Auction house contract for that. Here is the link for Auction house link
Note: This is not new, but I have some new insights on it.
For about three weeks now I regularly try to deploy the development-schema of my CloudKit Container to production, using the CloudKit Dashboard:
It spins for exactly a minute to then tell me "There was a problem loading the environment's status"
This is not new, many other questions face this as well:
Error CloudKit Dashboard - There was a problem loading the environment's status
Does iCloud need to be in the Production environment in order to use in Production?
iCloud dashboard: Cannot deploy CloudKit schema to Production
Apple support told me to
look at https://developer.apple.com/forums/thread/656723 (try again after a day with stable network)
use Safari and resetting browser settings to clear cache and cookies
"You may also try creating a new CloudKit container, rebuilding your schema, and then try again." => obviously doesn't work, because users have data on production
TL;DR:
Kill the timeout by running this in the console:
var id = window.setTimeout(function() {}, 0);
while (id--) {
window.clearTimeout(id); // will do nothing if no timeout with id is present
}
(the response is undefined — that's okay)
How I got there
So I started to look at the requests the site makes to the backend when I click "deploy". Chrome shows that the request to
https://p39-ckdatabasews.icloud.apple.com/r/v3/user/<container-name>/production/public/admin/deployment/status?team_id=<team-id>
is cancelled after 1.0 min.
Insight 1
The problem is with the production schema. I had used the Reset Development Environment before to make sure I hadn't messed that up myself, but this would have spared me that.
I used the Copy as cURL command (in Chrome, because it also copies the auth cookies, which Safari does not) and ran it in Terminal.
Interestingly, that does respond after 1'37 min. That's also what the X-Apple-Edge-Response-Time: 97244 header says.
If you know what to look for, the console will also tell you the the request timed out:
Insight 2
The server takes too long to respond (> 1min) and the client script times out (at 1 min)
Note: You can also get a response by right-clicking the request in Chrome and choosing "Replay XHR".
Solution
I tried to understand the JavaScript that sends the XHR request and modify the timeout, but I failed. However, you can apparently clear all timeouts that exist with
var id = window.setTimeout(function() {}, 0);
while (id--) {
window.clearTimeout(id); // will do nothing if no timeout with id is present
}
(from https://stackoverflow.com/a/8860203)
Running that while waiting for the response actually worked for me!
I'm attempting to create a dashboard for admins to allow them to reset a chrome device managed by GoogleAdmin using google apps script.
I don't see any way to perform a reset using Admin SDK API. Can this be done?
If you want to deprovision and/or disable a ChromeOS device
The supported actions when using the Directory API, according to the documentation here are:
deprovision: Remove a device from management that is no longer active, being resold, or is being submitted for return / repair, use the deprovision action to dissociate it from management.
disable: If you believe a device in your organization has been lost or stolen, you can disable the device so that no one else can use it. When a device is disabled, all the user can see when turning on the Chrome device is a screen telling them that it’s been disabled, and your desired contact information of where to return the device.
Taking this into account, this is how the request would look like:
POST https://admin.googleapis.com/admin/directory/v1/customer/{customerId}/devices/chromeos/{resourceId}/action
If you want to reboot and/or remote powerwash a ChromeOS device
However, if you simply plan on doing a powerwash or a reboot, you can make use of the below information:
REBOOT: Reboot the device. Can only be issued to Kiosk and managed guest session devices.
REMOTE_POWERWASH: Wipes the device by performing a power wash. Executing this command in the device will remove all data including user policies, device policies and enrollment policies.
Warning: This will revert the device back to a factory state with no enrollment unless the device is subject to forced or auto enrollment. Use with caution, as this is an irreversible action!
Taking this into account, this is how the request would look like:
POST https://admin.googleapis.com/admin/directory/v1/customer/{customerId}/devices/chromeos/{deviceId}:issueCommand
Apps Script
As for applying any of these in Apps Script, you will have to add the Admin SDK API advanced service and choose the directory _v1 version and simulate any of the above requests.
Code
Assuming you want to remote powerwash a device, you will have to write something similar to this:
let resource = {
YOUR_RESOURCE_HERE;
"commandType": "REMOTE_POWERWASH"
};
let customerId = 'CUSTOMER_ID';
let deviceId = 'DEVICE_ID';
AdminDirectory.Customer.Devices.Chromeos.issueCommand(resource, customerId, deviceId);
Not what you are looking for?
You can simply create a feature request on Google's Issue Tracker and provide the details with regards to your task by filling in the form here.
Reference
Directory API Manage ChromeOS Devices.
I'm using Sentry to log my errors, but there are errors I'm not able to fix (or could not be fixed by me) like
OSError (write error)
Or error that come from RQ (each time I deploy my app)
Or client errors (which are client.errors)
I can't just ignore them because I consume all my quota. How I can filter out this errors?
Here some references for interested people.
uwsgi: OSError: write error during GET request
Fixing broken pipe error in uWSGI with Python
https://github.com/unbit/uwsgi/issues/1623
I created a Gist for rate limiting the amount of events that are being send to Sentry:
https://gist.github.com/jurrian/e22f8e724b8499a29c5537e956f0dc7f
It uses ratelimitingfilter which can be configured to set a rate per minute, and additionally add a burst to start rate limiting after a number of events.
I get the same errors, but i never had any problems with my quota. But if you really want to filter it, you can just do it in your sdk:
https://docs.sentry.io/error-reporting/configuration/filtering/?platform=python
But beware, this could hide other errors as mentioned here:
https://github.com/pypa/warehouse/issues/679
To safe yourself some quota, you have two options:
Avoid forwarding events client side, thus preventing events being send to sentry at all. Have a look at the docs for available client-side filters. The drawback with this approach is of course that you need a new code deployment for any adjustment of client-side filters and some clients may not instantly reflect your code changes.
Avoid forwarding events on sentry's side, via inbound filters ([Project] > Project Settings > Inbound Filters). According to the sentry documentation on quota usage, events filtered via inbound filters are not affecting your quota.
Inbound filters include:
Common browser extension errors
Events coming from localhost
Known legacy browsers errors
Known web crawlers
By their error message
From specific release versions of your code
From certain IP addresses
Business plans and above also allow to filter events by error messages.
We need to fetch mutual friend data for each one of our new users. (We're currently doing that through the REST API.) In load testing for an upcoming traffic surge, we ran into API throttling, which breaks our production site. Oops!
In the Insights -> Diagnostics pane, it looks like they issue throttling warnings before they actually throttle. Is there some way we can monitor those limits in code so that we back off gracefully?
You will want to watch for the two errors coming back, then put your next call on a wait timer.
API_EC_TOO_MANY_CALLS Application request limit reached
API_EC_USER_TOO_MANY_CALLS User request limit reached
See: http://www.fb-developers.info/tech/fb_dev/faq/general/gen_10.html for more information.