Как управлять Объектами IDisposable, которые кэшируются?
, поэтому я не работаю с Allure, но я могу показать вам, как получить имя браузера, а затем вы можете попробовать применить к вашему делу.
Попробуйте изменить это:
var browserNameforSuit;
let bName = (async () => {
try {
browserNameforSuit = (await browser.getCapabilities()).get('browserName');
return browserNameforSuit;
} catch (err) {
return "Error or smth"
}
})();
На это:
var capsPromise = browser.getCapabilities();
var browserNameforSuit;
capsPromise.then(function (caps) {
browserNameforSuit = caps.get('browserName');
//if you need you can return the result to a var in order to user somewhere else
});
Это onComplete из моего conf.js
onComplete: function()
{
var browserName, browserVersion;
var capsPromise = browser.getCapabilities();
capsPromise.then(function (caps) {
browserName = caps.get('browserName');
browserVersion = caps.get('version');
platform = caps.get('platform');
//here I prepare the testConfig adding what I need//
//here I get the xml with the test results and create an html
new HTMLReport().from('./execution_results/reports/xml/xmlresults.xml', testConfig);
});//End Of capsPromise
},
Надеюсь помогает!
6 ответов
Доступные объекты всегда должны иметь ясного владельца, который ответственен за расположение их. Однако это - не всегда объект, который создал их. Кроме того, владение может быть передано.
Понимая это, решение становится очевидным. Не располагайте, перерабатывайте! Вам нужен не только способ получить ресурс от кэша, но также и способ возвратить его. В той точке кэш является владельцем снова и может принять решение сохранить ресурс для будущего использования или расположить его.
public interface IDisposableItemCache<T> : IDisposable
where T:IDisposable
{
/// <summary>
/// Creates a new item, or fetches an available item from the cache.
/// </summary>
/// <remarks>
/// Ownership of the item is transfered from the cache to the client.
/// The client is responsible for either disposing it at some point,
/// or transferring ownership back to the cache with
/// <see cref="Recycle"/>.
/// </remarks>
T AcquireItem();
/// <summary>
/// Transfers ownership of the item back to the cache.
/// </summary>
void Recycle(T item);
}
править: Я просто заметил, что эта идея также существует в Spring, где это называют пулом объектов. Их BorrowObject и ReturnObject методы соответствуют методам в моем примере.
К (неправильной) кавычке Raymond Chen: Каждый кэш без политики истечения является утечкой
Так, установите ясную политику истечения кэша и позвольте кэшу расположить их как нормальный случай. Это все еще покидает завершение работы приложения, которое будет обработано.
Если Ваши неуправляемые ресурсы принадлежат процессу, можно позволить процессу выпустить их на завершении работы.
Если неуправляемые ресурсы не принадлежат процессу, необходимо обнаружить завершение работы, и explicitely Располагают кэшируемые элементы.
Если Вы не можете обнаружить завершение работы процесса надежно, и управляемые ресурсы являются дорогими, неуправляемые не являются, разделяют управляемое от неуправляемых ресурсов и позволяют кэшу сохранить только управляемые.
Когда неуправляемые ресурсы являются дорогими, таким образом, им нужно кэширование, и они не принадлежат процессу, и Вы не можете обнаружить завершение работы процесса надежно, и Вы не можете позволить себе пропустить их, затем Ваша проблема не может быть решена.
В первую очередь, тип, который переносит собственные ресурсы, должен быть finalizable, не просто доступным. Еще лучше используйте SafeHandle для обертывания собственных ресурсов.
Если кто-то не явно ответственен за то, что сказал, что они сделаны с объектом, и он может быть расположен, затем я думаю, что Вы - более обеспеченное разрешение GC заботиться о нем. Обратите внимание, что это должно быть finalizable, хотя, иначе GC не даст ему второй взгляд.
Вы могли отделить неуправляемые ресурсы от управляемого экземпляра и использовать диспетчера кэша для содержания ряда неуправляемых ресурсов. Управляемый объект попытается получить экземпляр неуправляемого ресурса из диспетчера кэша, который или создаст один или приведет один свободный пример от кэша и возвратит его диспетчеру кэша (вместо того, чтобы расположить его сам) во время его распоряжения. Диспетчер кэша будет единственным ответственным объектом для выделения и освобождения неуправляемых ресурсов, когда это будет видеть, что это необходимо.
Можно решить это с фабрикой классов и IDisposable. Например:
public class CachedObject : IDisposable {
private int mRefCount;
private CachedObject(int something) {
mRefCount = 1;
}
public static CachedObject CreateObject(int something) {
CachedObject obj = LookupInCache(something);
if (obj != null) Interlocked.Increment(ref obj.mRefCount);
else obj = new CachedObject(something);
return obj;
}
private static CachedObject LookupInCache(int something) {
CachedObject obj = null;
// Implement cache lookup here, don't forget to lock
//..
return obj;
}
public void Dispose() {
int cnt = Interlocked.Decrement(ref mRefCount);
if (cnt == 0) {
// Remove from cache
//
}
}
}
Объект должен быть расположен классом, который создает его. Так как Ваши вызывающие стороны не создали объекты в кэше, у них нет бизнеса, избавляющегося от них, также.
Я хотел бы удостовериться, что Ваш метод фабрики называют чем-то как "GetClass", а не "CreateClass", чтобы подчеркнуть, что вызывающая сторона не ответственна за создание, и поэтому не для распоряжения.