🤍

Coroutines + Legacy = 💣

Kotlin Coroutines는 현재 Android 개발 생태계에서 가장 주목받는 기술 중 하나일 것입니다. 글을 읽는 여러분들은 이미 각자의 서비스에 이 기술을 적용했거나 검토하는 중이라 생각하고 있습니다. 이 글은 Cupist의 Java-MVP to Kotlin-MVVM 전환 작업이 한창이던 2019년 상반기의 기록의 일부이며 읽는 분들에게 조금이나마 도움이 되었으면 하는 마음으로 인상적으로 느꼈던 이슈와 그 원인에 대한 이야기를 공유하고자 합니다. 물론 각자의 서비스마다 만날 수 있는 이슈는 조금 더 다양할 것이고 "뭐 이런 실수를 해?"라는 생각을 가지실 수도 있습니다만, 저도 만나기 전까지 생각 못 했었거든요. 여러분들은 같은 실수를 하지 마시길 바랍니다.

코루틴이라구요?

네, 코루틴이요. 어차피 정식 릴리즈 된 거 바로 진행 해보자 라는 마음으로 도입을 시작하였습니다. 이미 많은 글에서 이 기술이 전통적인 안드로이드 개발과 다른 기술이 가지지 못하는 이점에 대해 다루고 있기 때문에 따로 설명하지 않으려고 합니다. Cupist의 안드로이드 개발자들 또한 이러한 글을 참고하며 이 기술이 우리에게 주는 이점에 대해 기대를 하였고 개발을 진행함과 동시에 감탄하였고 장미빛 미래를 생각하며 새로운 안드로이드 앱 버전을 릴리즈하였습니다. 그리고 Fabric의 리포트에 불꽃같이 올라오는 Crash를 보며 무언가 잘못되었다는 것을 느꼈죠...

android.database.sqlite.SQLiteDatabaseLockedException: database is locked (code 5)
#################################################################
Error Code : 5 (SQLITE_BUSY)
Caused By : The database file is locked.
(database is locked (code 5): , while compiling: PRAGMA cache_size)
#################################################################
Plain Text

친구야 오랜만이야!

친구야 나도 오랜만이야! 그런데 너 쫌 많이 바쁘구나?

Legacy Code의 늪

위에서 언급한 바와 같이 이 작업은 Java + MVP로 구성된 앱 메인 코드를 Kotlin + MVVM으로 마이그레이션 및 리팩토링 작업의 일부였습니다. 기존에 Callback 방식 등으로 구현되었던 비즈니스 로직을 코루틴을 이용하여 리팩토링하는 과정에서 일부 SQLite 접근 로직들이 IO Dispatcher를 통해 실행되도록 수정되었습니다. 그리고 IO Thread에서 DB 쓰기 작업을 하는 중 생각하지도 않은 다른 Activity의 Main Thread에서 DB 읽기를 시도하였고 앱이 죽어 나가기 시작했습니다.

원인도 어느 정도 파악되었으니 빠르게 고쳐야겠다는 마음에 IO Dispatcher에서 동작하는 SQLite의 Transaction Mode를 IMMEDIATE로 변경하여 핫픽스 하고 "어휴.. 큰일 날뻔했다.."라 생각하였습니다. (아니 이미 난건데..?) 업데이트 후 진정된 Crash Report를 보며 안도함을 느끼며 Fabric의 Non-Fatals Report를 확인하는 순간 이 이슈의 숨겨진 이면을 알게 되었습니다.

java.lang.IllegalStateException: attempt to re-open an already-closed object
Plain Text

친구야 나도 오랜만이야~

아...그래...그냥 뭔가 엄청 잘못 만든 거였구나!!!

역시나 범인은 Dispatchers.IO를 이용하여 생성된 CoroutinScope의 Thread들 이었습니다. IO Dispatcher로 실행된 로직들의 동작 Thread는 다를 수 있기 때문에 서로 불꽃 같은 자원 쟁탈전을 벌이며 이슈가 발생하고 있었습니다. (문서를 잘 읽으라고 친구 )

테스트 코드 짤 시간

가장 빠르고 확실하게 해결 할 수 있는 방법은 SQLite 관련 동작을 전부 Main으로 돌리는 것입니다. 다른 후보로는 newSingleThreadContext를 이용한 별도의 ThreadContext를 생성하는 것 정도가 될 것입니다. (이름은 Dispatchers.Database로 하는 게 좋겠군! ) 해결된다는 것은 확실하지만 확인차 테스트 코드를 작성합니다.

우선 이슈 재현 및 해결을 위하여 테스트용 SQLite Wrapping Class인 TestDatabase를 생성하였습니다. 객체를 하나씩 저장하고 지울 수 있는 간단한 기능이 있지만, 테스트를 위하여 Insert 할 때마다 2초씩 sleep 한다는 결점을 부여하였습니다. 이제 본격적으로 테스트 코드를 작성해 봅니다. 해당 이슈의 테스트는 SQLite와 Coroutines를 지원해야 하기 때문 Robolectric과 kotlinx-coroutines-test(1.1.1 버전 사용 됨)를 사용합니다.

Robolectric

Running tests on an Android emulator or device is slow! Building, deploying, and launching the app often takes a minute or more. That's no way to do TDD. There must be a better way. Robolectric is a framework that brings fast and reliable unit tests to Android.

http://robolectric.org/

Kotlin/kotlinx.coroutines

Test utilities for kotlinx.coroutines. This package provides testing utilities for effectively testing coroutines. Add kotlinx-coroutines-test to your project test dependencies: dependencies { testImplementation 'org.jetbrains.kotlinx:kotlinx-coroutines-test:1.3.0-RC2' } Do not depend on this project in your main sources, all utilities are intended and designed to be used only from tests.

https://github.com/Kotlin/kotlinx.coroutines/tree/master/kotlinx-coroutines-test

@ExperimentalCoroutinesApi
@RunWith(RobolectricTestRunner::class)
class DatabaseTest {
private val mainThreadSurrogate = newSingleThreadContext("UI thread")
lateinit var database: TestDatabase
val testName = "TEST_NAME"
@Before
fun setup() {
Dispatchers.setMain(mainThreadSurrogate)
database = TestDatabase(ApplicationProvider.getApplicationContext())
}
@After
fun tearDown() {
Dispatchers.resetMain()
mainThreadSurrogate.close()
}
@Test
fun whenInsertTestData() {
database.insert(testName)
val users = database.getAll()
val user = users.find {
it.name == testName
}
assertNotNull(user)
assertEquals(1, users.size)
}
}
Kotlin

기본적인 세팅이 된 모습으로 SQLite 및 코루틴을 초기화하고 SQLite가 정상 동작하는지 확인하는 간단한 테스트가 추가되었습니다. 이제 Fabric에서 질리도록 본 이슈를 재현해보도록 합니다.

작성될 케이스는 아래와 같습니다.

•

IO Thread(정확히는 DefaultDispatcher의 Worker 중 하나이겠지만 편의상 IO Thread라 칭하겠습니다.)에서 쓰기 작업 시도 중 대략 0.5초 후 또 다른 IO Thread에서 쓰기 시도

•

Main Thread에서 쓰기 작업 시도 중 대략 0.5초 후 IO Thread에서 쓰기 시도

@ExperimentalCoroutinesApi
@RunWith(RobolectricTestRunner::class)
class DatabaseTest {
...
@Test(expected = IllegalStateException::class)
fun givenWhileInsertingOnIO_whenInsertOnIO_thenException() = runBlocking(Dispatchers.Default) {
launch(Dispatchers.IO) {
database.insert(testName)
}
delay(500)
launch(Dispatchers.IO) {
database.insert(testName)
assertTrue(false)
}
Unit
}
@Test(expected = IllegalStateException::class)
fun givenWhileInsertingOnMain_whenInsertOnIO_thenException() = runBlocking(Dispatchers.Default) {
launch(Dispatchers.Main) {
database.insert(testName)
}
delay(500)
launch(Dispatchers.IO) {
database.insert(testName)
assertTrue(false)
}
Unit
}
}
Kotlin

... 뭔가 올바르지 않은 모양으로 보입니다. 최대한 시나리오대로 동작하도록 의도하였지만 이런 타입의 이슈(타이밍이라 불리는)를 위한 테스트 코드를 많이 작성하지 않아 익숙하지 않네요. 그래도 기대한 대로 Exception이 발생하며 테스트는 성공하는 것으로 보입니다. 이제 이 코드를 베이스로 Main과 직접 생성한 ThreadContext를 이용해서 테스트를 진행합니다.

작성될 케이스는 아래와 같습니다.

•

Main Thread에서 쓰기 작업 시도 중 대략 0.5초 후 Main Thread에서 쓰기 시도

•

Database Thread에서 쓰기 작업 시도 중 대략 0.5초 후 Database Thread에서 쓰기 시도

위 케이스에서 두 번째 Insert는 첫 번째 Insert가 완전히 종료된 후 동작하게 될 것입니다.

@ExperimentalCoroutinesApi
@RunWith(RobolectricTestRunner::class)
class DatabaseTest {
private val databaseContext = newSingleThreadContext("Database thread")
...
@Test
fun givenWhileInsertingOnMain_whenInsertOnMain_thenInserted() = runBlocking(Dispatchers.Default) {
launch(Dispatchers.Main) {
database.insert(testName)
}
delay(500)
launch(Dispatchers.Main) {
database.insert(testName)
}.join()
assertEquals(2, database.getAll().size)
}
@Test
fun givenWhileInsertingOnDatabase_whenInsertOnDatabase_thenInserted() = runBlocking(Dispatchers.Default) {
launch(databaseContext) {
database.insert(testName)
}
delay(500)
launch(databaseContext) {
database.insert(testName)
}.join()
assertEquals(2, database.getAll().size)
}
}
Kotlin

테스트를 동작시키면 예상대로 두 테스트 모두 통과하는 것을 확인할 수 있습니다. 그럼 이제 핫픽스를 위한 선택의 시간입니다.

에필로그

newSingleThreadContext의 값비싼 비용에 비하여 Glam App의 SQLite는 그리 무겁게 사용되지 않습니다. 결국, 이러한 비용 문제와 레거시 코드와의 이슈 보장 등의 이유로 우선 SQLite는 Main에서 작업하는 것으로 결정되어 핫픽스 되었습니다. 이상적이지 않고 완벽과는 거리가 먼 방법이지만 효과는 확실하여 빠르게 이슈가 진정되는 것을 확인하였습니다. 생각해보면 레거시 코드를 그대로 사용하지 않고 바로 Room으로 Migration 했다면 만나지 않았을 이슈였을지도 모릅니다. (아니, 다른 이슈를 만났을 꺼야! ) 지금이라도 늦지 않았기 때문에 이젠 Jetpack을 타러 갑니다. 안녀엉~!