Hello,
We are trying to evaluate X-Modules, but after installation on our on-prem bitbucket server, the plugin is not usable. Whenever we try to use any X-Modules feature, including the settings page, we simply get a Connection Timeout error and nothing else.
The logs also don’t show much more than that.
Is there anything specific the module wants to connect to which might be blocked in our internal firewall?
Any help is much appreciated.
Thanks,
Emanuel May
Hello Emanuel,
I would suggest to try to disable “Long polling” mode of the app. To do that go to “Administration | Git X-Modules” page, uncheck “Use Long Polling” checkbox, and apply the change.
By default Git X-Modules app keeps an open connection from Bitbucket to your browser and thus the UI reacts immediately to the changes in the repositories without any need to refresh the page. By disabling “Long polling”, the open connection is replaced with periodic queries with the same effect of refreshing UI automatically. If your firewall doesn’t allow long lasting connections but allows short periodic queries, this would address the issue.
However there’s a chance that when you open “Administration | Git X-Modules” page you’ll still see “Connection Timeout” and thus you’ll be unable to uncheck this checkbox. I this case I would suggest 2 solutions:
Use another browser or another network that wouldn’t be behind firewall just to disable “Long polling”. After disabling it, I would expect Git X-Modules to work even through the firewall.
Git X-Modules can be fully automated using REST. To disable “Long polling” with ‘curl’ run
BITBUCKET_URL=http://yourBitbucketServer:7990
BITBUCKET_USER=yourBitbucketUser
BITBUCKET_PASSWORD=yourBitbucketPassword
curl -u $BITBUCKET_USER:$BITBUCKET_PASSWORD $BITBUCKET_URL/rest/gx/1.0/scheduler/schedule --header "Content-Type: application/json" --header "X-Atlassian-Token:no-check" -d @disable-long-polling.json
where disable-long-polling.json (2.8 KB) file is attached to this post.
I hope that after disabling “Long polling” everything will work fine. Meanwhile we will try to address the problem at the app level to prevent it from happening in the first place.
Hey, thanks for the answer.
Indeed, the Administration Page has already a timeout. Browsers don’t seem to make a difference and I can’t use another network configuration due to company policies, but I will try the REST approach.
I will let you know if this fixes the issue. Thanks so far!
Edit:
That was quick! This did indeed fix the issue. Thank you very much!
I’m sorry, but there is still something wrong. I can use the UI now without issues it seems, but I can’t get it to actually add code after creating a module in a repository. I followed the “quick start guide” which works fine until the very end of the guide, after which absolutely nothing happens for me. I see no new files in the repository and even deleting and recreating modules does nothing. The Status always says that no modules are configured yet.
This looks weird. Could you create support ZIP and send it to support@tmatesoft.com?
If you move cursor over status area, “Sync” button appears. If you click it, does it help?
Is it possible that the firewall forbids some queries (e.g. the one that notifies UI about changes in the modules)? To check this you can use Chrome, click F12, go to Network tab and try to remove and add the module. Are there errors in the list of queries?
Does the support zip only contain information regarding the plugin? Because to me it looks like it contains all logs, including sensitive information, which means I will not be allowed to share this.
Sync button also does nothing (popup appears for a second and disappears again, but no change in repo).
I found an exception in the logs/console though, maybe this brings us further:
org.tmatesoft.util.error.GxException: Repository hook com.bit-booster.bb.hooks:bbPreReceive failed\n\tat org.tmatesoft.gitx.app.job.GxSyncModulesJob.lambda$onSyncActivityCompleted$1(GxSyncModulesJob.java:139)\n\tat java.util.HashMap.forEach(HashMap.java:1289)\n\tat org.tmatesoft.gitx.app.job.GxSyncModulesData.forEachRepository(GxSyncModulesData.java:67)\n\tat org.tmatesoft.gitx.app.job.GxSyncModulesJob.onSyncActivityCompleted(GxSyncModulesJob.java:131)\n\tat sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)\n\tat sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)\n\tat sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)\n\tat java.lang.reflect.Method.invoke(Method.java:498)\n\tat org.tmatesoft.util.event.GxProgressMonitor$EventAction.run(GxProgressMonitor.java:439)\n\tat org.tmatesoft.util.event.GxProgressMonitor.runEventActions(GxProgressMonitor.java:308)\n\tat org.tmatesoft.util.event.GxProgressMonitor.lambda$runEventActions$5(GxProgressMonitor.java:302)\n\tat java.util.ArrayList.forEach(ArrayList.java:1259)\n\tat org.tmatesoft.util.event.GxProgressMonitor.runEventActions(GxProgressMonitor.java:302)\n\tat org.tmatesoft.util.event.GxProgressMonitor.close(GxProgressMonitor.java:192)\n\tat org.tmatesoft.util.event.GxProgressMonitor.close(GxProgressMonitor.java:205)\n\tat org.tmatesoft.util.event.GxProgressMonitor.complete(GxProgressMonitor.java:222)\n\tat org.tmatesoft.gitx.app.job.GxSyncModulesJob.run(GxSyncModulesJob.java:84)\n\tat org.tmatesoft.gitx.app.job.GxSyncModulesJob.run(GxSyncModulesJob.java:42)\n\tat org.tmatesoft.framework.job.GxJobService.lambda$doCall$0(GxJobService.java:99)\n\tat org.tmatesoft.framework.bitbucket.scope.GxBitbucketScopeRunnerService.lambda$runForScope$1(GxBitbucketScopeRunnerService.java:53)\n\tat com.atlassian.stash.internal.user.DefaultEscalatedSecurityContext.call(DefaultEscalatedSecurityContext.java:59)\n\tat org.tmatesoft.framework.bitbucket.scope.GxBitbucketScopeRunnerService.runForScope(GxBitbucketScopeRunnerService.java:53)\n\tat org.tmatesoft.framework.job.GxJobService.doCall(GxJobService.java:93)\n\tat org.tmatesoft.framework.job.GxJobService.call(GxJobService.java:65)\n\tat org.tmatesoft.framework.bitbucket.job.GxBitbucketJobService.runJob(GxBitbucketJobService.java:209)\n\tat com.atlassian.scheduler.core.JobLauncher.runJob(JobLauncher.java:134)\n\tat com.atlassian.scheduler.core.JobLauncher.launchAndBuildResponse(JobLauncher.java:106)\n\tat com.atlassian.scheduler.core.JobLauncher.launch(JobLauncher.java:90)\n\tat com.atlassian.scheduler.caesium.impl.CaesiumSchedulerService.launchJob(CaesiumSchedulerService.java:435)\n\tat com.atlassian.scheduler.caesium.impl.CaesiumSchedulerService.executeClusteredJob(CaesiumSchedulerService.java:430)\n\tat com.atlassian.scheduler.caesium.impl.CaesiumSchedulerService.executeClusteredJobWithRecoveryGuard(CaesiumSchedulerService.java:454)\n\tat com.atlassian.scheduler.caesium.impl.CaesiumSchedulerService.executeQueuedJob(CaesiumSchedulerService.java:382)\n\tat com.atlassian.scheduler.caesium.impl.SchedulerQueueWorker.executeJob(SchedulerQueueWorker.java:66)\n\tat com.atlassian.scheduler.caesium.impl.SchedulerQueueWorker.executeNextJob(SchedulerQueueWorker.java:60)\n\tat com.atlassian.scheduler.caesium.impl.SchedulerQueueWorker.run(SchedulerQueueWorker.java:35)\n\tat java.lang.Thread.run(Thread.java:748)\n
It looks like it complains about a repository hook. I have not set up any hooks, but we have a number of plugins that control or restrict repositories and branches (for example “Control Freak”). Could there be a conflict of some kind?
You’re right, it’s “Control Freak” app that prevents changes in the repository. When our app is about to update the branch to commit that would contain X-Modules in it, it runs all other hooks and fails if any other hook rejects such an update.
I don’t have experience with “Control Freak” but according to this screenshot, the easiest thing you could try would be to exempt X-Modules special user (Git X-Modules <support@tmatesoft.com>) from policies enforcements:
To see an example of a commit authored by Git X-Modules <support@tmatesoft.com>, have a look at our demo repository:
https://test.tmatesoft.com/projects/GXM/repos/monorepo/commits
(it’s the top commit there).
Probably we could introduce an option to bypass other hooks, this could be another solution to the problem.
And as I see the ‘status’ is indeed wrong in such scenario, we’ll try to reproduce and fix the problem.
Yes, that solved the issue. Thank you very much. It seems I can finally evaluate the plugin :)
Just for the record: I’ve created an issue for the ‘wrong status’ problem
https://issues.tmatesoft.com/issue/GXM-84
