intelliJ를 사용해서 프로젝트 시작 중 아래와 같은 에러가 발생했을때

CreateProcess error=206, 파일 이름이나 확장명이 너무 깁니다

아래와 같은 플러그 인으로 해결

요약

문제 원인 :

gradle 에서 java를 실행할때, commandline으로 실행을 하는데, classpath의 길이가 너무 길어서 발생

이것을 manifest jar로 만들어서 실행해줌


gradle-util-plugins

When classpath for a Gradle JavaExec task is long, Windows command executions give error because of limitation to command line length greater than 32K.

With a number of classpath dependencies in a large project, typically JavaExec Gradle task fails with error "The filename or extension is too long" and this would be a stopping error. To solve this issue, use ManifestClasspath plugin.

ManifestClasspath plugin creates a manifest jar for jar files in the classpath of JavaExec task and sets the classpath with manifest jar.

Usage

To use the plugin, define a dependency in build script and have plugin entry in Gradle project.

build.gradle snippet to use ManifestClasspath plugin

Build script snippet for plugins DSL for Gradle 2.1 and later

plugins {
  id "com.github.ManifestClasspath" version "0.1.0-RELEASE"
}

Build script snippet for use in older Gradle versions or where dynamic configuration is required

buildscript {
  repositories {
    maven {
      url "https://plugins.gradle.org/m2/"
    }
  }
  dependencies {
    classpath "gradle.plugin.com.github.viswaramamoorthy:gradle-util-plugins:0.1.0-RELEASE"
  }
}

apply plugin: "com.github.ManifestClasspath"

https://github.com/viswaramamoorthy/gradle-util-plugins

'BackEnd > ETC' 카테고리의 다른 글

Git remote: Permission to  (0) 2020.03.08
http 상태 코드  (0) 2020.01.19
CQRS란 ?  (1) 2020.01.19
STORM 정리  (0) 2017.12.18

Git remote: Permission to

깃허브 사용중에 아래와같은 에러가 발생하는 경우가 있었다.

remote: Permission to elasticsearchstudy/SaturdaySpring.git denied to DaeyunKim.

fatal: unable to access 'https://github.com/elasticsearchstudy/SaturdaySpring.git': The requested URL returned error: 403

처음엔 프로젝트에서 권한 문제인줄알았는데

찾아보니 아래와 같이 다시 터미널에서 입력해주고 다시 시도하니 된다.

$ git remote set-url origin git@github.com:elasticsearchstudy/SaturdaySpring.git

해결 : https://stackoverflow.com/questions/47465644/github-remote-permission-denied

'BackEnd > ETC' 카테고리의 다른 글

[gradle] CreateProcess error=206  (0) 2020.04.25
http 상태 코드  (0) 2020.01.19
CQRS란 ?  (1) 2020.01.19
STORM 정리  (0) 2017.12.18

# Http 상태 코드

 

내가 자주 보았던 Http 응답 코드는 404, 500, 200, 등등이었는데 앞자리에 따라서 의미가 다르다. 잘 몰랐지만 이번에 정리를 해보자

 

http 응답 상태는 3자리 숫자로 나타낸다.

 

첫번째 숫자는 응답의 클래스(분류)로 구분된다.

마지막 두 자리는 클래스나 분류 역할을 하지는 않지만 분류에 따라 다양하다.



| 앞 번호 | 의미 |

|-|-|

|1 (조건부 응답)| 요청을 받았으며, 프로세스를 계속 한다.|

|2 (성공)| 요청을 성공적으로 받았으며, 인식했고 수용하였다. |

|3 (리다이렉션 완료)| 요청완료를 위해 추가 작업 조치가 필요함|

|4 (요청 오류)| 요청의 문법이 잘못됬거나 요청을 처리 할 수 없다.|

|5 (서버 오류)| 서버가 명백히 유효한 요청에 대해 충족을 실패 했다.|

 

**예시**

100 : 요청자는 요청을 계속 한다. 서버는 이 코드를 제공하여 요청의 첫번째 부분을 받았으며 나머지를 기다리고 있음을 나타냄.

101 : 요청자가 서버에 프로토콜을 전환을 요청했고, 서버는 이를 승인하는 중.

 

200 : 서버가 요청을 제대로 처리 했다.

201 : 성공적으로 요청되었으며 서버가 새로운 리소스를 작성함

202 : 서버가 요청을 접수는 했는데, 아직 처리가 되지 않음

204 : 콘텐츠 없음, 서버가 요청을 성공적으로 처리 했지만 콘텐츠를 제공하지 않음

205 : 서버가 요청을 성공적으로 처리 했지만, 콘텐츠를 표시하지 않는다.

206 : 서버가 get 요청의 일부만 성공적으로 처리함

 

301 : 요청한 페이지를 새 위치로 영구적으로 이동( GET Head 요청에 대한 응답으로 이 응답을 표시하면 요청자가 자동으로 새 위치로 전달됨)

302 : 현채 서버가 다른 위치의 페이지로 요청을 응답하고 있지만, 요청자는 향후 요청시 원래 위치를 계속 사용함.

 

400 : 서버가 요청 구문을 인식하지 못할때

401 : 인증이 필요한 요청이지만, 권한이 없음, 또는 인증안됨을 뜻함

403 : forbidden 에러 : 서버가 요청을 거부!!

404 : 서버가 요청한 페이지를 찾을 수 없을 때

408 : 서버의 요청 대기가 시간을 초과 하였다.

 

500 : 서버에 오류가 발생하여 요청을 수행 할 수 없다.

501 : 서버에 요청을 수행할 수 있는 기능이 없다

502 : 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에 잘못된 응답을 받았다.

504 : 서버가 게이트웨이나 프록시 역할을 하고 있거나, 업스트림 서버에서 제때 요청을 받지 못함

...이외에도 다양한 응답 상태가 존재한다.





참고 : [Http 상태 코드 /위키백과](https://ko.wikipedia.org/wiki/HTTP_%EC%83%81%ED%83%9C_%EC%BD%94%EB%93%9C)

'BackEnd > ETC' 카테고리의 다른 글

[gradle] CreateProcess error=206  (0) 2020.04.25
Git remote: Permission to  (0) 2020.03.08
CQRS란 ?  (1) 2020.01.19
STORM 정리  (0) 2017.12.18

CQRS

*Command Query Responsibility Segregation : *
명령과 쿼리의 역할을 구분한다는 의미

Command란? CURD(Create-Insert-Update, Delete)를 나타낸다.
Query란 ? Select(데이터 조회)의 책임을 분리한다는것이다.
버란트 마이어의 CQS가 CQRS의 출발이고, CQRS를 처음 소개 한 분은 Greg Young이다.

탄생
전통적인 CURD 아키텍처 기반에서 Application을 개발 및 운영 하다 보면 자연스럽게 Domain Model의 복잡도가 증가된다.
이때 유지보수에 대한 Cost는 증가되고, Domain Model은 점점 설계시 의도한 방향과는다르게 변질된다. Application Business 정책이나 제약은 거의 대 부분 데이터 변경작업에서 처리되고 Read는 단순 조회가 대부분이기 때문에, 이 두 업무를 동일한 도메인 모델로 처리하게 되면 도메인의 속성들의 복잡도가 증가하고, 설계와는 다르게 다른 방향으로 변질이 된다.

그래서 나온것이 '명령을 처리하는 책임!', '조회를 처리하는 책임!' 을 분리 구현하자! 라는 개념이 CQRS의 핵심이다.

참고 : 나만 모르고 있던 CQRS & EventSourcing
추가 자료 최신-기술-cqrs-처음-도입하기

'BackEnd > ETC' 카테고리의 다른 글

[gradle] CreateProcess error=206  (0) 2020.04.25
Git remote: Permission to  (0) 2020.03.08
http 상태 코드  (0) 2020.01.19
STORM 정리  (0) 2017.12.18

복합 이벤트 처리 (Complex Event Processing)에 대한 연구를 하다 보니 오픈 소스는 Esper, Siddhi 기반 으로한 WSO2 등 많은 엔진이 있다.

하지만 데이터스트림을 처리하는데 있어서 오픈 프레임워크는 spark와 storm 대표적이다.

Spark 같은 경우는 Memory를 기반으로 분산 컴퓨팅을 지원한다고 하는데 , 추후에 시간이 있을 때 다시 정리를 하겠습니다.

STORM 같은 경우에는 오픈소스로 오래 되었고, 안정적이라고한다.

아파치 스톰 홈페이지 http://storm.apache.org/index.html

 

Why use Storm?

Apache Storm is a free and open source distributed realtime computation system. Storm makes it easy to reliably process unbounded streams of data, doing for realtime processing what Hadoop did for batch processing. Storm is simple, can be used with any programming language, and is a lot of fun to use!

Storm has many use cases: realtime analytics, online machine learning, continuous computation, distributed RPC, ETL, and more. Storm is fast: a benchmark clocked it at over a million tuples processed per second per node. It is scalable, fault-tolerant, guarantees your data will be processed, and is easy to set up and operate.

Storm integrates with the queueing and database technologies you already use. A Storm topology consumes streams of data and processes those streams in arbitrarily complex ways, repartitioning the streams between each stage of the computation however needed. Read more in the tutorial.

스톰을 쓰는 곳은 트위터, 야후, 엘프, 필립보드, 그룹폰 등등 많은 곳에서 쓰고 있다.

 

Storm 구성하는 기본 요소

Topology, stream, spout, bolt 로 구성

 

Topology

스톰의 분산 연산 구조로 stream, spout, bolt로 구성됨.

spout과 bolt 간의 연관관계를 정의해서 데이터의 관계를 정의해 놓은 것 .

: 하둡과 같은 배치 처리 시스템의 잡과 거의 비슷하지만, Batch Job은 연산의 처음과 끝지점이 명확하게 정의되어 있는 반면에

Storm의 Topology는 죽이거나 언디플로이 할 때까지 계속 동작.

Stream

튜플은 스톰의 기본 데이터 구조체이며, key-value pair의 목록이며, 스트림은 연속된 튜플들로 정의를 함.

스톰 튜플을 CEP의 이벤트로 생각하면 된다.

 

Spout

Spout에서는 데이터를 읽어들이는 데이터 소스(Storm Topology로들어가는 입구)이다. 또한 데이터를 나타내는 tuple을 생성하는데, Tuple은 데이터를 보관하는 단위를 나타낸다.

Adaptor로 동작하는데 데이터 소스와 연결을 맺고 데이터를 튜플로 변환하여 스트림으로 튜플을 내보내는 일을 한다.

Bolt

 

Bolt는 읽어드린 데이터를 처리하는 함수, CEP에서는 연산자, 실시간연산으로 생각하면됨, 입력값으로 데이터 스트림을 받고, 로직에 따라 다른 bolt로 넘겨주거나 종료.

 

위의 그림과 같이 토폴로지는 하나의 spout과 여러 개의 bolt로 이루어진다.

 

https://trenbe.onelink.me/uRnQ/b38091c7

'BackEnd > ETC' 카테고리의 다른 글

[gradle] CreateProcess error=206  (0) 2020.04.25
Git remote: Permission to  (0) 2020.03.08
http 상태 코드  (0) 2020.01.19
CQRS란 ?  (1) 2020.01.19

+ Recent posts