Conversation
|
This requires at least 4 changes:
|
pczuj
force-pushed
the
issue/JPERF-1106-gather-apache2-logs
branch
from
e33e49b to
df3bd05
Compare
| sharedHomeSsh.host, | ||
| sharedHome.get().remoteSharedHome | ||
| ) | ||
| val loadBalancerResultsSource = (provisionedLoadBalancer.loadBalancer as? DiagnosableLoadBalancer) |
There was a problem hiding this comment.
First time used this as? syntax. Casts are usually bad, however given the circumstances of our current model I think this is a better solution than putting a new field into ProvisionedLoadBalancer and I'm also not certain if adding methods to LoadBalancer would be a good idea. Extending the interface and detecting it allows for wrapping of DiagnosableLoadBalancer implementations without losing the feature.
There was a problem hiding this comment.
Indeed casts are bad. See https://github.com/atlassian/aws-infrastructure/blob/release-2.29.0/src/main/kotlin/com/atlassian/performance/tools/awsinfrastructure/api/jira/DataCenterFormula.kt#L360:
if (loadBalancer is ApacheProxyLoadBalancer) listOf(loadBalancer::updateJiraConfiguration) else emptyList()Fortunately, ApacheProxyLoadBalancer will match both is/as? casts, so it will function.
We need hooks API to avoid further tight coupling. If the apache logs are necessary, then we can merge the tech debt. But if not, then let's skip that part.
| import com.atlassian.performance.tools.aws.api.StorageLocation | ||
| import com.atlassian.performance.tools.infrastructure.api.loadbalancer.LoadBalancer | ||
|
|
||
| interface DiagnosableLoadBalancer : LoadBalancer { |
There was a problem hiding this comment.
Name suggestions welcome
| import com.atlassian.performance.tools.infrastructure.api.loadbalancer.LoadBalancer | ||
|
|
||
| interface DiagnosableLoadBalancer : LoadBalancer { | ||
| fun gatherDiagnostics(location: StorageLocation) |
There was a problem hiding this comment.
Name suggestions welcome
| import com.atlassian.performance.tools.aws.api.StorageLocation | ||
| import com.atlassian.performance.tools.infrastructure.api.loadbalancer.LoadBalancer | ||
|
|
||
| interface DiagnosableLoadBalancer : LoadBalancer { |
There was a problem hiding this comment.
We could make that LoadBalancer-agnostic, however that would make the model more abstract and that possibly could make it harder to understand. Looking for thoughts on that.
pczuj
force-pushed
the
issue/JPERF-1106-gather-apache2-logs
branch
2 times, most recently
from
38c9b50 to
693a749
Compare
pczuj
force-pushed
the
issue/JPERF-1106-gather-apache2-logs
branch
from
693a749 to
05c1ddd
Compare
|
I migrated the new tests to use AssertJ |
|
@dagguh do you see value in this change? If not we may want to decline it. We used the logs in our internal experiment to diagnose problem and we already know that the problem is with Jira memory usage and not load balancer. Load balancer proxy error was only a symptom of product having CPU/IO problems. |
|
Overall reuse of |
pczuj
force-pushed
the
issue/JPERF-1106-gather-apache2-logs
branch
from
05c1ddd to
af09430
Compare
|
This is ready for review again. I'm not planning to add integration test for the logs. |
| - Make `StartedNode` a `MeasurementSource`. | ||
|
|
||
| ## Fixed | ||
| - Let every `MeasurementSource` inside `Jira` finish its gathering even if one of them fails. Fix [JPERF-1114]. |
There was a problem hiding this comment.
Let's split those changes. One sounds good, while the other needs some further considerations.
| sharedHomeSsh.host, | ||
| sharedHome.get().remoteSharedHome | ||
| ) | ||
| val loadBalancerResultsSource = (provisionedLoadBalancer.loadBalancer as? DiagnosableLoadBalancer) |
There was a problem hiding this comment.
Indeed casts are bad. See https://github.com/atlassian/aws-infrastructure/blob/release-2.29.0/src/main/kotlin/com/atlassian/performance/tools/awsinfrastructure/api/jira/DataCenterFormula.kt#L360:
if (loadBalancer is ApacheProxyLoadBalancer) listOf(loadBalancer::updateJiraConfiguration) else emptyList()Fortunately, ApacheProxyLoadBalancer will match both is/as? casts, so it will function.
We need hooks API to avoid further tight coupling. If the apache logs are necessary, then we can merge the tech debt. But if not, then let's skip that part.
Not sure how to judge that. We wanted to take a look at the appache logs when diagnosing a problem recently. We used JAR built from this code to do so, however didn't really find anything useful other than confirmation that the load balancer just times out on communication with the product. We no longer have an immediate problem to diagnose, so that would mean that the logs are not necessary. Question is if we wouldn't waste the effort if the diagnostic need will repeat itself, yet the code for it won't be merged and e.g. will have conflicts with the current master. |
3 participants
No description provided.