'Cache'에 해당하는 글 3건

TLSv1 deprecated

Daily/Prog 2021. 11. 24. 01:59

20년이 지나도 멈추지 않는 삽질 이야기.

 

WARN: This connection is using TLSv1 which is now deprecated and will be removed in a future release of Connector/J

 

warning 은 신호등에 비유하면 주황색과 같다. 가도 그만 멈추어도 그만인데 난 될수 있으면 멈추는 스타일이다. 그 바람에 또 소중한 시간들을 낭비한다. 위 경고는 TLSv1 / TLSv1.1 이 deprecated 되었으며, 이 프로토콜을 사용한 연결시 MySQL Connector/J Version 8.0.26 버전부터 발생하는 메시지다.

 

참고: https://docs.oracle.com/cd/E17952_01/connector-j-8.0-relnotes-en/news-8-0-26.html

 

3 Changes in MySQL Connector/J 8.0.26 (2021-07-20, General Availability)

3 Changes in MySQL Connector/J 8.0.26 (2021-07-20, General Availability) Version 8.0.26 is the latest General Availability release of the 8.0 series of MySQL Connector/J. It is suitable for use with MySQL Server versions 8.0, 5.7, and 5.6. It supports the

docs.oracle.com

해결은 간단하다. 난 8.0.27 버전을 사용중이었지만 8.0.26 아래 버전으로 다운그레이드 하면 되는데... 이제부터 삽질 시작이다.



Intellij 에서 gradle + java 프로젝트.

모듈은 두개. DB 와 API.

 

// DB module : build.gradle
dependencies {
    ...
    runtimeOnly 'mysql:mysql-connector-java:8.0.25'
    ...
}

// API module : build.gradle
dependencies {
    implementation project(':DB')
}

 

간단하다. DB 모듈에서 MySQL Connector/J 8.0.25 를 정의하고, API 모듈에서 그걸 가져다 썼다. 하지만 경고는 계속해서 나타났다. External Libraries 를 확인해보니 8.0.25 / 8.0.27 두 개 버전이 모두 import 되어 있었다. cache 문제겠거니 하고 기본적인 캐시 삭제 작업들을 시작했다.

 

  • Invalidate Caches -> Invalidate and Restart
  • Project Settings -> Libraries -> MySQL Connector/J 8.0.27 버전 삭제
  • $USER\.gradle\caches 디렉토리 삭제

 

gradle-library-duplicate

 

하지만 이 짓들을 다 해도 MySQL Connector/J 8.0.27 는 계속해서 살아났고 경고가 콘솔에 도배됐다. Find Usages 에서 확인해보니 API 모듈에서 사용중이란다. DB 모듈에서는 8.0.25 를 불러오는데, API 모듈에서 그걸 불러오면 8.0.27 로 변신한다니 이게 대체 무슨...

 

혹시라도 다른 라이브러리에 중복되어 있는지 dependency tree 도 확인해 봤다.

 

 

(DB)  mysql:mysql-connector-java:8.0.25

(API) mysql:mysql-connector-java:8.0.25 -> 8.0.27

 

다른 곳에서 정의 되어 있는건 한개도 없는데 그냥 바뀌어 버린다.ㅋㅋ

 

한참을 삽질한 끝에 밝혀낸 원인은...

gradle 에 정의한 두개의 플러그인 간에 의존성들이 달라 발생한 문제였다.

결국 재정의 했다...

 

dependencies {
    runtimeOnly 'mysql:mysql-connector-java:8.0.25'
    implementation project(':DB')
}

 

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,

CloudFront

Server/AWS 2019. 8. 20. 18:43



CloudFront 는 .html, .css, .js 및 이미지 파일과 같은 정적 및 동적 웹 콘텐츠를 사용자에게 더 빨리 배포하도록 지원하는 AWS 의 CDN 서비스이다. 전 세계 주요지역에 CloudFront POP(엣지 로케이션) 이 위치하고 있어 해당 캐시 서버에서 오리진(EC2 인스턴스나 ELB, S3 버킷 등) 의 파일을 받아 클라이언트에게 빠르게 응답하는 기능을 한다. 캐시 서버는 오리진(origin)으로부터 파일을 캐시하고 나면 해당 파일이 수정되기 전까지는 오리진에 연결하지 않고 빠르게 클라이언트에 응답할 수 있다. 


CloudFront 는 이미지나 동영상 등의 리소스가 보관된 S3 를 오리진으로 설정하는 것이 일반적이며, 운영시 꼭 필요한 서비스 중 하나이다.



CloudFront 의 설정/배포 방법


  1. CloudFront 에 캐시할 오리진(예제에서는 S3 사용) 의 주소(test.s3.amazonaws.com) 메모.
  2. 콘솔의 CloudFront 에서 [Create Distribution] 으로 배포 설정.
  3. Origin Domain Name 의 S3/ELB 목록에서 캐시할 오리진을 선택하고 Alternate Domain Names(CNAMEs) 에 원하는 CloudFront 도메인 설정.
  4. 나머지 설정은 버킷 접근 권한/정책, https, SSL 설정 정도... 이렇게 세팅하고 배포 생성하기를 시작하면 수분안에 각 캐시 서버에 오리진이 배포된다.


CloudFront 배포 도메인은 http://aabbccdd112233.cloudfront.net 형식이며 설정한 CNAME 으로 대체할 수 있다. 브라우저에서 해당 리소스의 헤더에서 X-Cache: Hit from cloudfront 가 확인되면 정상적으로 캐시되고 있는 것이다. 캐시 유지 시간이 지나서 CloudFront가 오리진에 접속하여 파일을 가져왔을 때에는 Miss from cloudfront 라고 표시된다.



캐시 삭제


캐시 파일은 기본적으로 24시간 동안 유효하며, 특정 파일을 즉시 갱신해야 할 경우 콘솔 등에서 무효화(Invalidation) 요청을 통해 캐시된 파일을 삭제시킬 수 있다.




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,

Tomcat Caching

Daily/Prog 2017. 1. 2. 18:58

톰캣 + 스프링 환경.

운영서버는 자동화로 배포까지 깔끔하지만, 개발서버는 매번 war 파일을 생성하고 ftp로 업로드하여 배포를 했었다.

/recources/application.properties 를 수시로 바꿔가면서 배포를 했었는데,

며칠전에는 변경된 application.properties 내용이 갱신되지 않은 현상이 있었다.

혹시나 해서 톰캣을 재부팅 하여 갱신은 됐는데 왜 이러한 현상이 생긴건지.


톰캣을 재부팅하여 해결된걸 보면 톰캣의 캐시설정과 관련된거 같은데...

매번 내용 갱신이 잘되다가 갑자기 안된것도 이상하고...

배포 후 WAS 재시작은 필수인가...


검색 중에 톰캣 컨텍스트 옵션중에 정적 자원을 캐싱해 주는 cachingAllowed 란 놈을 찾아냈다.

cachingAllowed 의 디폴트 값은 true 란다.

이 녀석을 꺼주면 재부팅이 필요없기를 바라면서 과감히 꺼본다.


* /etc/tomcat8/context.xml


<Context cachingAllowed="false">
cs



해당 메뉴얼 - https://tomcat.apache.org/tomcat-8.0-doc/config/resources.html




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,