Shared - jolokiaService should resolve or reject requests in case of ajax error

[tadayosi]

Currently the operations provided by jolokiaService such as readAttribute, writeAttribute, execute, search, etc. rely on the default ajaxError callback in case of ajax error happening while performing Jolokia requests.

hawtio-next/packages/hawtio/src/plugins/shared/jolokia-service.ts

Lines 293 to 332 in 50a83c4

	return (xhr: JQueryXHR) => {
	switch (xhr.status) {
	case 401:
	case 403: {
	const url = new URL(window.location.href)
	// If window was opened to connect to remote Jolokia endpoint
	if (url.searchParams.has(PARAM_KEY_CONNECTION)) {
	// ... and not showing the login modal
	if (url.pathname !== '/connect/login') {
	this.jolokia?.then(jolokia => jolokia.stop())
	const redirectUrl = window.location.href
	url.pathname = '/connect/login'
	url.searchParams.append('redirect', redirectUrl)
	window.location.href = url.href
	}
	} else {
	// just logout
	userService.isLogin().then(login => {
	log.debug('Logging out due to jQuery ajax error: status =', xhr.status)
	login && userService.logout()
	})
	}
	break
	}
	default: {
	errorCount++
	const updateRate = this.loadUpdateRate()
	const validityPeriod = updateRate * (errorThreshold + 1)
	setTimeout(() => errorCount--, validityPeriod)
	if (errorCount > errorThreshold) {
	eventService.notify({
	type: 'danger',
	message: 'Connection lost. Retrying...',
	// -100ms is to not overlap between update and notification
	duration: updateRate - 100,
	})
	}
	}
	}
	}

Since this callback is not aware of resolve or reject callback provided by each Promise that wraps a Jolokia operation, the processing of the request should hang in case of ajax error. This can happen when for some reason the remote Jolokia endpoint starts to stop serving requests, for instance due to authentication being expired or any other internal server error.

This should be actually mostly fine, because then the user would need to refresh the page or authenticate again to restore the working status anyway. So, practically we've observed no issues with it yet. However, it should be still considered well-behaved to make sure the operation terminates in such an exceptional case. That's why it's marked as enhancement.

[grgrzybek]

Hmm, I was thinking about it, but maybe it should be more long term goal - including Jolokia switch to Fetch API? (jolokia/jolokia#580)...

[tadayosi]

@grgrzybek If I remember it correctly, the issue was filed right after this fix: 4963ed3
it already fixed the issue for the list operation. What we need to do would be to apply the similar fix to the rest of Jolokia operations. So I think it can be fixed in a short term.