Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make it possible to have distributed ProjectRegistry #9848

Merged
merged 50 commits into from
May 31, 2018
Merged

Make it possible to have distributed ProjectRegistry #9848

merged 50 commits into from
May 31, 2018

Conversation

gazarenkov
Copy link
Contributor

What does this PR do?

  • Remake ProjectRegistry as interface and make current (inmemory) registry as default implementation
  • Create RegisteredProject as interface (moved to shared package) with corresponding DTO
  • Create experimental PersistingProjectRegistry implementation which caches current project state in the shared Project storage (under //.che/tmp/projectConfig directory)
  • RootDirPathProvider instead of direct using property for flexibility (caused a lot of changes in code)

What issues does this PR fix or reference?

as stated in the title

Docs PR

n/a yet

gazarenkov and others added 30 commits February 25, 2018 17:33
# Conflicts:
#	ide/che-core-ide-app/src/main/java/org/eclipse/che/ide/context/AppContextImpl.java
…re no 'project' volume defined"

This reverts commit 127a79e.
…ode, remove highlighter from the source folder field
@@ -84,4 +86,11 @@ public void shouldUnWatchByMatcher() throws Exception {

verify(fileWatcherByPathMatcher).unwatch(ID);
}

private static class DummyRootProvider extends RootDirPathProvider {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here will be better use Mock instead of Dummy implementation, this is allow avoid duplication

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure it simplifies a lot but fixed, thanks )

@vparfonov
Copy link
Contributor

ci-test

@codenvy-ci
Copy link

ci-test build report:
Build details
Test report
selenium tests report data
docker image: eclipseche/che-server:9848
https://github.com/orgs/eclipse/teams/eclipse-che-qa please check this report.

@@ -189,12 +190,12 @@
@Inject
public ResourcesPlugin(
@Named("che.jdt.workspace.index.dir") String indexPath,
@Named("che.user.workspaces.storage") String workspacePath,
RootDirPathProvider pathProvider,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what if keep in constructor
@Named("che.workspaces.storage") String workspacePath
and will use provider for this property

    bind(String.class)
        .annotatedWith(Names.named("che.workspaces.root.dir"))
        .toProvider(RootDirPathProvider.class);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why to make this logic more complex?

what needed is to inject configuration object (called RootDirPathProvider)?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you do not mind, I'll put in my five cents. Though technically there is almost no difference between two cases, I find it more comfortable to remember, to navigate and to use (in IDE) RootDirPathProvider class instead of a variable named "che.workspaces.root.dir" or "che.workspace.storage", it's much easier to access provider class (or property) documentation and so on. Probably it is caused by the way object oriented programmer thinks - in objects and classes, not properties and values.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ок

import org.eclipse.che.api.project.shared.RegisteredProject;
import org.eclipse.che.api.project.shared.dto.RegisteredProjectDto;
import org.eclipse.che.dto.server.DtoFactory;

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

javadoc

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as I said it is still experimental impl (kinda placeholder) and not bound yet, of course javadoc will be added

DtoFactory.getInstance().createDtoFromJson(json, RegisteredProjectDto.class));
}
} catch (Exception e) {
e.printStackTrace();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LOG.error ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, will do


@Inject(optional = true)
@Named("che.user.workspaces.storage")
protected File rootFile = null;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you will use constructor injection then you can reuse it in tests.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well, I do not see any blocker for tests, object just need to be prepared according to the contract.

@skabashnyuk
Copy link
Contributor

[INFO] Processed 49 files (1 non-complying).
[ERROR] Found 1 non-complying files, failing build
[ERROR] Non complying file: /home/codenvy/workspace/che-pullrequests-test-ocp/plugins/plugin-maven/che-plugin-maven-server/src/main/java/org/eclipse/che/plugin/maven/server/rest/MavenServerService.java
[JENKINS] Archiving disabled

please run mvn fmt:format

@gazarenkov
Copy link
Contributor Author

@skabashnyuk ok, sorry for format but that's what I edited with GH, probably was not a good idea though...
BTW, I do not think it is reasonable to ask for reformatting just because there are 4 spaces in empty line (added by editor) - I would say we need to check with formatter whether it can be more reasonable.
WDYT?

@skabashnyuk
Copy link
Contributor

BTW, I do not think it is reasonable to ask for reformatting just because there are 4 spaces in empty line (added by editor) - I would say we need to check with formatter whether it can be more reasonable.
WDYT?

I'm not sure that issue is only in spaces. I would recommend configuring your ide to use google's formatted and space settings.

@gazarenkov
Copy link
Contributor Author

I compared 2 files before commented and yes, only spaces and as I said I used GH editor and what I did is just removing unused comments.

@skabashnyuk
Copy link
Contributor

We can't run selenium test until we have formatting issue. Maven can't compile sources. It has to be fixed somehow.

@@ -318,8 +319,7 @@ private RegisteredProject doImportInternally(
projectConfigRegistry.put(newProjectConfig, true, false);
}

return projectConfigRegistry
.get(wsPath)
return Optional.ofNullable(projectConfigRegistry.getOrNull(wsPath))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can use return projectConfigRegistry.get(wsPath) here if I'm not mistaken, but up to you

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@RomanNikitenko I guess you are right, just considered it as risky at that time :)
if you or @dkuleshov think it is totally safe - will fix it immediatelly
WDYT?

Copy link

@dkuleshov dkuleshov May 30, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we can safely use projectConfigRegistry.get(wsPath) since it already returns Optional.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, done

@gazarenkov
Copy link
Contributor Author

@skabashnyuk sure, fixed alltogether

/**
* Provides path for projects root directory using: env variable 'CHE_PROJECTS_ROOT' (which is set
* by workspace API == "project" volume configured) if not - uses 'che.user.workspaces.storage'
* property otherwise - default with '/project' directory (backward comptible solution)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo comptible - compatible

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fair enough :) thanks, fixed


private final RegisteredProjectFactory registeredProjectFactory;
private final FsManager fsManager;
private final FileCache cache;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would say it isn't a cache but rather a persistence manager.
Beside this I would add cache (basically a map) not to access the fs for every get operations.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tolusha well, we have this kind of map in default (inmemory, local) registry but an idea is just opposite - to simply reuse a projects volume as a shared for all the machines place (it should be by nature). So it call shared data all the time, not a local map.

So, I'd consider it as a (persisted, not optimized by performance) data cache.

As I said it is experimental and one of the reason is to also learn how it might impact on overall performance. May be it will be OK with this implementation, maybe we can reduce amount of calls, maybe it is not acceptable at all, I do not know yet and would not like to start with complex (data grid like solution) either.

Does it make sense?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes sense for me, thx.

@musienko-maxim
Copy link
Contributor

ci-test

@codenvy-ci
Copy link

ci-test build report:
Build details
Test report
selenium tests report data
docker image: eclipseche/che-server:9848
https://github.com/orgs/eclipse/teams/eclipse-che-qa please check this report.

@musienko-maxim
Copy link
Contributor

In the functionality that is covered by selenium tests we did not find new regression. We have 4 failed tests which failed in the unexpected place but after rerun they passed as well.

@gazarenkov gazarenkov merged commit 00ca159 into eclipse-che:master May 31, 2018
@gazarenkov gazarenkov removed the status/code-review This issue has a pull request posted for it and is awaiting code review completion by the community. label May 31, 2018
@benoitf benoitf added this to the 6.7.0 milestone Jun 4, 2018
hbhargav pushed a commit to hbhargav/che that referenced this pull request Dec 5, 2018
* Adding pipeline

* del jenkinsfile

* Make exec agent not to use setsid for other than Linux envs

* revert pom.xml

* goformat

* get projects folder from workkspace configuration

* Merge remote-tracking branch 'upstream/master'

* clean code

* clean code

* Fix calculation Projects Root so it wont cause NPE if there are no 'project' volume defined

* Revert "Fix calculation Projects Root so it wont cause NPE if there are no 'project' volume defined"

This reverts commit 127a79e.

* Fix calculation Projects Root so it wont cause NPE if there are no 'project' volume defined

* replace provided attribute values with stored (src, out) in PlainJavaProjectType

* fix PlainJavaProjectType for getting rid and deprecate using SettableValueProvider

* remove comented code

* hide brouse source folder button, set source folder field as disabled

* hide the browse source button, set source folder field to read only mode, remove highlighter from the source folder field

* adapt test for current changes on UI, set save button to enable state

* apply formatting

* fs cache PT

* fix order of steps in the test

* Refactor RegisteredProject to make it possible to cache it (as DTO) to local file

* cache Projects and PTs to files

* Make it possible to have several impls for ProjectRegistry preparing it to be distributed across multi machines env

* merge upstream

* merge upstream

* merge upstream

* Update MavenServerService.java

* clean code

* small fix

* small fix

* small fix
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants