I am using hystrix api version 1.5.4. I am seeing that the method withExecutionIsolationThreadTimeoutInMilliseconds is deprecated. What is the alternate method instead?
public HystrixHelloCommand(String message) {
super(HystrixCommand.Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("MyGroup")).andCommandPropertiesDefaults(
HystrixCommandProperties.Setter()
.withCircuitBreakerEnabled(true).withExecutionIsolationThreadTimeoutInMilliseconds(2000)));
}
As per the Doc it is replaced by withExecutionTimeoutInMilliseconds and this is what it says:
com.netflix.hystrix.HystrixCommandProperties.Setter.withExecutionIsolationThreadTimeoutInMilliseconds(int)
As of 1.4.0, replaced with
HystrixCommandProperties.Setter.withExecutionTimeoutInMilliseconds(int).
Timeouts are no longer applied only to thread-isolated commands, so a
thread-specific name is misleading
Related
Let's say I have these classes:
Old_Class
New_Class
If this exists ->something(new Old_Class()) or Old_Class::staticMethod() or $oldClass->methodCall() I want a code sniff to warn "Old_Class usage found, recommend using New_Class instead".
I found this sniff Generic.PHP.ForbiddenFunctions but it only seems to catch built-in php functions is_array, is_null, etc.
Do I need to write a custom sniff for this?
If so, what token should I added to the register() function to catch on?
I couldn't use a built-in one. I had to write one using T_STRING.
public function register()
{
return [
T_STRING,
];
}
public function process(PHP_CodeSniffer_File $phpcsFile, $stackPtr)
{
$tokens = $phpcsFile->getTokens();
if ($tokens[$stackPtr]['content'] === 'Old_Class') {
$error = 'Old_Class usage found, consider using New_Class instead.';
$phpcsFile->addWarning($error, $stackPtr);
}
}
I know this is a fairly old question, but there are two possible solutions I'm aware of:
The Slevomat coding standard for Codesniffer includes a sniff to report usage of any of an array of forbidden classes
Static analysis tools are another approach for this. If you mark a class with the #deprecated annotation, I know from personal experience that Psalm will flag it with the DeprecatedClass issue, and if you can't fix them all at once, you can add them to the baseline, which will suppress the issue, but keep track of it, so you can still use Psalm in continuous integration and not break on existing issues. I believe PHPStan has similar functionality.
I am currently working on fixing some BestPractice-Warnings on a bigger project. There i have a few instances where forms are called and are awaited before doing more stuff, this is mostly some dialogs. To await form the following code is used very often:
Object formRun;
//declare args and stuf...
formRun = classfactory.formRunClass(args);
formRun.init();
//call methods on formRun (display,run,etc...)
formRun.wait();
The problem i am facing now is that 'wait()' seems to be deprecated and i don't get how to replace or fix this. I have seen that some devs declared the form as 'Object' to get rid of this warning (didn't work by the way, this will still be detected), but this is a late-bound-call which should also be avoided...
Has anyone else had this issue ? i tried calling this method using the system.reflection namespace but this doesn't look right and is also much more code in x++ than should be needed for such a simple task.
TLDR
I think this is a false positive from the best practice checks. To get rid of the best practice warnings, you can add them to the list of suppressed best practices or add a best practice suppression in code.
Details
In Deprecated APIs (June 2017) it says for the wait method of Object:
Overview
Used to block and wait for an interaction/operation and notify to
unblock.
Reason for deprecation
These calls are deprecated for all objects except formRun and it’s
derivatives.
Migration notes
Calls to these APIs from formRun or it’s derivatives are allowed.
Calls to these APIs from any other object should be removed.
When you do a metadata search for code:"formRun.wait()", you will also get a lot of results (more than 1000 on version 8.0). This is further indication that the method is not deprecated for FormRun.
That said, you may want to take a look at the following link which mentions a formRun.lifecycleHelper() to which event handlers can be added. I haven't personally tried this so far, but it may be applicable to your case.
FormRun.wait, Box and ChangeCompany - a poor cocktail
Using the last version of chilkat 9.5.0.0
Same problem from this topic
http://www.chilkatforum.com/questions/8569/delphi-http-memory-leak-with-getquickstr
Im using threads and memory leak is extreme!!
This code doesn't solve the problem.
CkHttp_ClearBgEventLog(HttClient);
CkHttp_CloseAllConnections(HttClient);
Tried to create and dispose component every iteration and same after every "get" or "post" request after using these methods:
CkHttp_PostUrlEncoded()
CkHttp__quickGetStr()
But, nothing helps.
The ClearBgEventLog method is part of a set of "background/async" methods and properties for the HTTP class that have long ago been deprecated and will be removed.
You should instead use the Async methods where the Async version of the method ends in "Async" and returns a Task object. For example, QuickGetAsync.
I have an interface, ILoader, on which I have defined an extension method CheckLoaderDatabaseConnection:
//the extension method
public static class LoaderExtensions
{
public static void CheckLoaderDatabaseConnection(this ILoader loader)
{
//data access stuff
}
All the doumentation out there tells me I have to use shims when I want to stub an extension method because the method is static and it can't be stubbed.
True, it doesn't work in Moq because I've tried it.
But I can stub the interface in Fakes:
var loader = new MyNamespace.Fakes.StubILoader() { };
In my unit test, I pass in the stub to the constructor of the concrete instance I'm testing and when it gets to this line:
loader.CheckLoaderDatabaseConnection();
It calls the stubbed method (which does nothing) and works ok.
Why is this? I must be missing something. I haven't had to use shims here at all (though I can't stub it in Moq - when I try that, the real world extension is called & the whole thing blows up)
No, the extension method wasn't getting invoked but after rebooting from a blue screen of death earlier the extension method is now getting invoked and the unit test is failing as I would expect.
Don't understand how this was working for several days though; something weird & I don't think this question can be answered.
I am starting to use Unity 2 , having happily used earlier versions. I notice that the IUnityContainer.BuildUP(object obj) method has been removed. Why has this happened?
It's here, that's for shure. It's just moved to extension methods.
http://msdn.microsoft.com/en-us/library/microsoft.practices.unity.unitycontainerextensions_members(v=PandP.20).aspx
Perhaps you don't have
using Microsoft.Practices.Unity
In some cases you'll have to add it when migrating from unity 1.2
The following overload is replacement for IUnityContainer.BuildUp(object obj)(actualy BuildUp(T obj)) becouse params ResolverOverride[] resolverOverrides are optional
http://msdn.microsoft.com/en-us/library/ff662062(v=PandP.20).aspx, so your code should compile without any changes