Commits are only showed after a couple of minutes

[francis]

Hi Pablo,

I'm trying to understand how the subversoin plugin works.

* I'm committing a change with a commit message containing a JIRA key

* I check the subversion repositories page and see that the additional commit has been 'indexed'
Before it was 770/770, and now 771/771

* In the subversion browser tab, I see that the commit is available

When I access the corresponding JIRA issue, the subversion action tab is empty.

When I come back a couple of minutes later, the subversion action tab contains the correct commit.

What I'm puzzled about is the delay between the moment the plugin indexes the commit and the moment the commit is visible in the subversion action tab.

Francis

[Kinto Soft]

Subversion Plus (which is a fork of the Atlassian JIRA Subversion plugin) scans the Subversion repositories in time inervals scheduled by a JIRA Service:

JIRA > Administration > System > Advanced > Services > Subversion Indexing Process Scheduler

The commits shown on the JIRA issue and project Subversion tab panel are fetched from the indexed (cached) data, so the latest commits are not visibe until the indexer process is fired and the latest commits scanned from the Subversion Server.

Furthermore, Subversion Plus shows the index progress:

latest indexed commit / latest index in the repository

in your case 770/770 means that all the commits have already been indexed. When you created the 771 commit, during some time the index would be 770/771 until the indexer process is fired and the 771 commid indexed. Then the progress is updated to: 771/771

On the other hand, Subversion Plus also bundles a custommized version of the Polarion Web client for Subversion which fetches the data directly from the server, so it is not affected by any delay. You can see all the commits just before they have been created. The expections are: the commit graphs and the statistics views which are build against the cached/indexed data rather the realtime Subversion server data.

[Kinto Soft]

Subversion Plus (which is a fork of the Atlassian JIRA Subversion plugin) scans the Subversion repositories in time inervals scheduled by a JIRA Service:

JIRA > Administration > System > Advanced > Services > Subversion Indexing Process Scheduler

The commits shown on the JIRA issue and project Subversion tab panel are fetched from the indexed (cached) data, so the latest commits are not visibe until the indexer process is fired and the latest commits scanned from the Subversion Server.

Furthermore, Subversion Plus shows the index progress:

latest indexed commit / latest index in the repository

in your case 770/770 means that all the commits have already been indexed. When you created the 771 commit, during some time the index would be 770/771 until the indexer process is fired and the 771 commid indexed. Then the progress is updated to: 771/771

On the other hand, Subversion Plus also bundles a custommized version of the Polarion Web client for Subversion which fetches the data directly from the server, so it is not affected by any delay. You can see all the commits just before they have been created. The expections are: the commit graphs and the statistics views which are build against the cached/indexed data rather the realtime Subversion server data.

[Kinto Soft]

That said, I am surprised about the delay between the latest indexed commit and when it is displayed on JIRA. Subversion Plus uses a H2 database instance to store all the indexed data and commits should available to be displayed on JIRA just immediatelly after they have been indexed as the databse commit transaction is set to one. I'll investigate it bacause I don't understand it. Maybe there is some tables cached in memory by default because some H2 configuration out of the box. I've to review all the database connections in order to resolve another estrange performance issue detected by other user in heavily loaded environments. I will care about yours too to during the review and I'll come back wether I found something.

[Kinto Soft]

I've changed the way how Suversion Plus internally manages the database connections. I did not see anything strange regarding the delay you mentioned, but maybe it might be a collateral effect resolved by this improvement. Might you try the latest 4.0 version?