'refresh'에 해당되는 글 6건

  1. 2020.07.21 [Terraform] apply 후 생성 된 정보 구하기.
  2. 2020.06.16 [Spring] @RefreshScope 적용 시 반영이 잘 안될 때
  3. 2017.12.06 [Elasticsearch] Refresh interval while bulk request (2)
  4. 2016.09.30 [Git] 리모트 브랜치 목록 새로고침.
  5. 2015.12.09 [Elasticsearch - The Definitive Guide] Making Changes Persistent
  6. 2014.08.04 [ElasticSearch] Refresh/Flush/Optimize - by elasticsearch.org

[Terraform] apply 후 생성 된 정보 구하기.

ITWeb/개발일반 2020. 7. 21. 08:44

Terraform  을 이용해서 인프라 구성을 한 후에 생성된 정보를 얻어 와야 할 때가 있습니다.

특정 정보만 구하고 싶을 경우 output 설정을 이용해서 얻을 수 있는 방법과 state 를 이용해서 얻을 수 있는 방법이 있습니다.

 

[참고문서]

https://www.terraform.io/docs/commands/output.html

 

tf 설정 파일 내 output 설정을 합니다.

resource "aws_instance" "allinone" {
...중략...
  count = 3
}

output "private_ip" {
  value = "${aws_instance.allinone.*.private_ip}"
}
# 변수 정보를 정상적으로 호출 하지 못할 경우 실행
$ terraform refresh

$ terraform output 변수명
-->
$ terraform output private_ip
[
  "10.0.25.14",
]

 

아래와 같이 하면 모든 state 정보를 return 해 줍니다.

 

$ terraform state pull

 

Trackbacks 0 : Comments 0

Write a comment


[Spring] @RefreshScope 적용 시 반영이 잘 안될 때

ITWeb/개발일반 2020. 6. 16. 14:51

일단 spring config server 에서 설정을 변경해서 적용 합니다.

 

POST , /actuator/refresh 를  실행 합니다.

 

그럼 기대 하는 건 변경 된 설정 값이 반영이 되어 있어야 한다는 것입니다.

 

그러나 반영이 안되어 있어서 디버깅 하다 아래와 같이 event 를 잡아서 처리를 해주니 잘되는 것을 확인 했습니다.

 

  @EventListener(RefreshScopeRefreshedEvent.class)
  public void onRefresh() {
    log.debug("triggering ----> {}", watcherThreshold);
  }

참고해서 보셔야 하는 코드는 아래 입니다.

/*
 * Copyright 2012-2020 the original author or authors.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      https://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package org.springframework.cloud.context.scope.refresh;

import java.io.Serializable;

import org.springframework.beans.BeansException;
import org.springframework.beans.factory.config.BeanDefinition;
import org.springframework.beans.factory.support.BeanDefinitionRegistry;
import org.springframework.cloud.context.scope.GenericScope;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;
import org.springframework.context.ApplicationListener;
import org.springframework.context.event.ContextRefreshedEvent;
import org.springframework.core.Ordered;
import org.springframework.jmx.export.annotation.ManagedOperation;
import org.springframework.jmx.export.annotation.ManagedResource;

/**
 * <p>
 * A Scope implementation that allows for beans to be refreshed dynamically at runtime
 * (see {@link #refresh(String)} and {@link #refreshAll()}). If a bean is refreshed then
 * the next time the bean is accessed (i.e. a method is executed) a new instance is
 * created. All lifecycle methods are applied to the bean instances, so any destruction
 * callbacks that were registered in the bean factory are called when it is refreshed, and
 * then the initialization callbacks are invoked as normal when the new instance is
 * created. A new bean instance is created from the original bean definition, so any
 * externalized content (property placeholders or expressions in string literals) is
 * re-evaluated when it is created.
 * </p>
 *
 * <p>
 * Note that all beans in this scope are <em>only</em> initialized when first accessed, so
 * the scope forces lazy initialization semantics.
 * </p>
 *
 * <p>
 * The scoped proxy approach adopted here has a side benefit that bean instances are
 * automatically {@link Serializable}, and can be sent across the wire as long as the
 * receiver has an identical application context on the other side. To ensure that the two
 * contexts agree that they are identical, they have to have the same serialization ID.
 * One will be generated automatically by default from the bean names, so two contexts
 * with the same bean names are by default able to exchange beans by name. If you need to
 * override the default ID, then provide an explicit {@link #setId(String) id} when the
 * Scope is declared.
 * </p>
 *
 * @author Dave Syer
 * @since 3.1
 *
 */
@ManagedResource
public class RefreshScope extends GenericScope implements ApplicationContextAware,
		ApplicationListener<ContextRefreshedEvent>, Ordered {

	private ApplicationContext context;

	private BeanDefinitionRegistry registry;

	private boolean eager = true;

	private int order = Ordered.LOWEST_PRECEDENCE - 100;

	/**
	 * Creates a scope instance and gives it the default name: "refresh".
	 */
	public RefreshScope() {
		super.setName("refresh");
	}

	@Override
	public int getOrder() {
		return this.order;
	}

	public void setOrder(int order) {
		this.order = order;
	}

	/**
	 * Flag to determine whether all beans in refresh scope should be instantiated eagerly
	 * on startup. Default true.
	 * @param eager The flag to set.
	 */
	public void setEager(boolean eager) {
		this.eager = eager;
	}

	@Override
	public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry)
			throws BeansException {
		this.registry = registry;
		super.postProcessBeanDefinitionRegistry(registry);
	}

	@Override
	public void onApplicationEvent(ContextRefreshedEvent event) {
		start(event);
	}

	public void start(ContextRefreshedEvent event) {
		if (event.getApplicationContext() == this.context && this.eager
				&& this.registry != null) {
			eagerlyInitialize();
		}
	}

	private void eagerlyInitialize() {
		for (String name : this.context.getBeanDefinitionNames()) {
			BeanDefinition definition = this.registry.getBeanDefinition(name);
			if (this.getName().equals(definition.getScope())
					&& !definition.isLazyInit()) {
				Object bean = this.context.getBean(name);
				if (bean != null) {
					bean.getClass();
				}
			}
		}
	}

	@ManagedOperation(description = "Dispose of the current instance of bean name "
			+ "provided and force a refresh on next method execution.")
	public boolean refresh(String name) {
		if (!name.startsWith(SCOPED_TARGET_PREFIX)) {
			// User wants to refresh the bean with this name but that isn't the one in the
			// cache...
			name = SCOPED_TARGET_PREFIX + name;
		}
		// Ensure lifecycle is finished if bean was disposable
		if (super.destroy(name)) {
			this.context.publishEvent(new RefreshScopeRefreshedEvent(name));
			return true;
		}
		return false;
	}

	@ManagedOperation(description = "Dispose of the current instance of all beans "
			+ "in this scope and force a refresh on next method execution.")
	public void refreshAll() {
		super.destroy();
		this.context.publishEvent(new RefreshScopeRefreshedEvent());
	}

	@Override
	public void setApplicationContext(ApplicationContext context) throws BeansException {
		this.context = context;
	}

}

 

refreshAll() 을 호출 하게 되어서 반영이 잘됩니다.

 

더불어 그냥 프레임워크에서 제공하는 @Scheduled 사용 하십시오.

 

  @Scheduled(fixedDelayString = "${megatoi.watcher.cpu.period}000")
  private void runner() {
    megatoiCheckerUtil.setWatcherThreshold(watcherThreshold);
    megatoiCheckerUtil.setPayload(getCheckQuery());
    megatoiCheckerUtil.setResourceType(ResourceType.CPU);
    megatoiCheckerUtil.commonRunner();
  }
Trackbacks 0 : Comments 0

Write a comment


[Elasticsearch] Refresh interval while bulk request

Elastic/Elasticsearch 2017. 12. 6. 14:00

작업 하면서 이상한 현상이 발생을 해서 분석 하다 보니 누구나 경험 할 수 있는 것 같아 올려 봅니다.


참고문서)

https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-update-settings.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-refresh.html


보통 bulk request 하기 전에 아래 설정을 적용하게 됩니다.

index.refresh_interval: "-1"

이 설정은 해당 index 의 settings 에서 설정 합니다.


이 설정을 하게 되면 bulk request 시 refresh action 을 수행 하지 않게 되는데요.

제가 경험한 현상은 disable 했음에도 불구하고 refresh thread 수가 증가 한다는 것이였습니다.


문제는 역시 elasticsearch 에 있었던 것이 아닌 저의 잘 못 이였습니다.

이유는 제가 정의한 mapping 정보에서 dynamic field 에 따른 template 구성이 영향을 주는 것이였습니다.

결과적으로 dynamic field 설정으로 색인 시 mapping 정보가 바뀌게 되고 이를 반영 하기위해 IndexService 가 updateMetaData() 를 수행 하게 됩니다. 이 과정에서 자동으로 refresh 가 발생을 하기 때문에 bulk request 시 왜 성능이 안나오지 하지 마시고 어떤 구성을 하셨는지 부터 분석해 보시면 더 좋을 것 같습니다.


Trackbacks 0 : Comments 2
  1. 2019.03.12 17:15 Modify/Delete Reply

    비밀댓글입니다

    • Favicon of https://jjeong.tistory.com BlogIcon jjeong 2019.03.19 11:29 신고 Modify/Delete

      그냥 문제가 생기면 저는 소스코드를 분석 해서 해결 하고 있습니다. :)

      또는 공홈의 래퍼런스 문서를 정독 합니다.

Write a comment


[Git] 리모트 브랜치 목록 새로고침.

ITWeb/개발일반 2016. 9. 30. 18:06

ide를 사용하다 보면 git remote branch 목록 sync 가 안될 때가 있습니다.

그래서 수동으로 명령어 날려 주는데요.

혹시 몰라 그냥 기록해 봅니다.



$ git remote prune origin --dry-run


dry run 해보시고 최종 실행 시에는 빼고 돌리시면 됩니다.

tags : branch, GIT, list, refresh
Trackbacks 0 : Comments 0

Write a comment


[Elasticsearch - The Definitive Guide] Making Changes Persistent

Elastic/TheDefinitiveGuide 2015. 12. 9. 17:02

per-segment search works 와 더불어 알아 두면 좋을 것 같아 올려봅니다.


원문링크)

https://www.elastic.co/guide/en/elasticsearch/guide/current/translog.html


원문 Snippet)

Elasticsearch uses this commit point during startup or when reopening an index to decide which segments belong to the current shard.

...중략...

Elasticsearch added a translog, or transaction log, which records every operation in Elasticsearch as it happens.


아래는 원문에 나와 있는 Making Changes Persistent 에 대한 flow 정리 입니다.


1) write in-memory buffer & translog

2) write new segment file without fsync

3) flush in-memory buffer (run refresh and not yet flush)

4) write in-memory buffer & append translog 

5) write new segment file (run flush)

6) flush in-memory buffer

7) write commit point on disk

8) flush filesystem cache with fsync

9) delete old translog

10) create new translog


기본적으로 refresh 와 flush 는 간단하게 아래와 같이 이해 하시면 됩니다.


- refresh

검색 가능한 상태로 만들어 줍니다.


- flush

fsync 작업을 합니다. (commit point 기록 및 translog 제거)

Trackbacks 0 : Comments 0

Write a comment


[ElasticSearch] Refresh/Flush/Optimize - by elasticsearch.org

Elastic/Elasticsearch 2014. 8. 4. 17:48

원본) http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/inside-a-shard.html


1. near real-time search

refresh apiedit

In Elasticsearch, this lightweight process of writing and opening a new segment is called a refresh. By default, every shard is refreshed automatically once every second. This is why we say that Elasticsearch has near real-time search: document changes are not visible to search immediately, but will become visible within one second.


2. making changes persistent

flush apiedit

The action of performing a commit and truncating the translog is known in Elasticsearch as a flush. Shards are flushed automatically every 30 minutes, or when the translog becomes too big. See thetranslog documentation for settings that can be used to control these thresholds.


3. segment merging 

optimize apiedit

The optimize API is best described as the forced merge API. It forces a shard to be merged down to the number of segments specified in the max_num_segments parameter. The intention is to reduce the number of segments (usually to 1) in order to speed up search performance.



Trackbacks 0 : Comments 0

Write a comment