I want disable decision caching, so in /repository/conf/security/entitlement.properties I tried
PDP.DecisionCaching.Enable=false
PDP.DecisionCaching.Enable=true and
PDP.DecisionCaching.CachingInterval=30
But, when enabling/disabling a resource for a user, I have to wait 10 minutes before the decision changes from permit/deny or I have to restart IS.
What should I do? Thanks
Related
I would like to be disable a web service inbound-gateway based on a database flag.
I have achieved this with other inbound adapters (e.g. file) by setting the auto-start attribute based on a SPEL expression which gets the database value.
Any advice on a good way to achieve this? I do not see an auto-start attribute on the ws:inbound-gateway.
Well, looks like it is a bug there around Lifecycle and in case of stopped state we should return to the client something like HttpStatus.SERVICE_UNAVAILABLE.
Please, raise a JIRA ticket on the matter and we will take care about that soon.
I see that <int-http:inbound-gateway> has similar problem, even if auto-startup is exposed there.
As a workaround I see something like ChannelInterceptor on the request-channel for you <int-ws:inbound-gateway>, which checks some variable and throws some exception (NoEndpointFoundException ?) from the preSend() implementation to notify WS client that the service isn't available.
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
I tired to lock user account using the admin console UI as described in http://isurad.blogspot.com/2014/09/how-to-lock-user-account-in-wso2.html. I made http://wso2.org/claims/identity/accountLocked = true. But still I can log in to the console using locked account.
Also tried to lock user account using the web service. Even this prints in the console,
{org.wso2.carbon.identity.mgt.services.UserIdentityManagementAdminService} - User account unconfirmed1 locked
Still I can log in to the console using locked account. What has gone wrong here?
The operation via the admin console is cached and is currently set to 15 mins. Hence the account lock should have worked but you need to wait 15 mins for this to come into effect. The web service calls should be immediate though.
I've got a django site that is producing a csv download. The content of the csv is dictated by user defined parameters. It's possible that users will set parameters that require significant thinking time on the server. I need a way of sustaining the http connection so the browser doesn't kick up an error message. I heard that it's possible to send intermittent http headers to do this. Can anyone point me in the right direction to set this up on a django site?
(unfortunatly I'm stuck with the possibility of slow reports - improving my sql won't mitigate this)
Don't do it online. Trigger an offline task, use a bit of Javascript to repeatedly call a view that checks if the task has finished, and redirect to the finished file when it's ready.
Instead of blocking the user and it's browser for 20 minutes (which is not a good idea) do the time-consuming task in the background. When the task will finish and generate the result simply notify the user so that he/she will just need to download the ready result.
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.