[jira] [Comment Edited] (NETBEANS-168) Background scanning process needs a rethink

2018-01-02 Thread Gili (JIRA)

[ 
https://issues.apache.org/jira/browse/NETBEANS-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16309122#comment-16309122
 ] 

Gili edited comment on NETBEANS-168 at 1/3/18 4:05 AM:
---

Assuming the cache could be updated transactionally, couldn't Netbeans use the 
previous cache snapshot until the new one is committed?

Or are you saying that for new projects (where there is no previous cache 
state) this is as good as a blocking process? If you're saying the latter then 
I don't think we can do better. Intellij behaves the same way. At the very 
least the user is free to open other projects, close existing ones, browse 
files, while the process completes.


was (Author: cowwoc):
Assuming the cache could be updated transactionally, couldn't Netbeans use the 
previous cache snapshot until the new one is committed?

> Background scanning process needs a rethink
> ---
>
> Key: NETBEANS-168
> URL: https://issues.apache.org/jira/browse/NETBEANS-168
> Project: NetBeans
>  Issue Type: Bug
>  Components: ide - Performance, java - Platform, platform - Execution
>Affects Versions: 8.2, Next
> Environment: NetBeans 8.2, Windows 10 x64
>Reporter: Christian Lenz
>Priority: Critical
>
> Often, while cloning, switching branch, merging, opening etc. etc. NetBeans 
> starts Background scanning for changes, but it is not real background, 
> because everything what you want to do then, like changing the branch, 
> commit, push, pull, open project, delete or whatever, is blocking by this 
> task and you can't cancel it, because it is essential.
> Either we need to rethink about this process like to make everything or most 
> of the stuff doing things in parallel or the task should really be 
> cancelable. It is a pain in the ass for big projects when they start to scan 
> for changes. 
> It is a real world case because you acan see it when you work on NetBeans 
> modules.
> Cheers
> Chris



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Comment Edited] (NETBEANS-168) Background scanning process needs a rethink

2018-01-03 Thread Christian Lenz (JIRA)

[ 
https://issues.apache.org/jira/browse/NETBEANS-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16310020#comment-16310020
 ] 

Christian Lenz edited comment on NETBEANS-168 at 1/3/18 6:20 PM:
-

I don't know, I only use IntelliJ or WebStorm or PHPStorm to test smth for some 
minutes but not for hours. For my daily work, I use NetBeans all the time.

So I have to try PHPStorm for our legacy PHP code base. Some versions ago, it 
was not really possible to open multiple projects which are independent from 
each other. So I have now 18 Projects in NetBeans open at the same time. 2 PHP, 
1 is really big. 2 gradle projects, some HTML5 projects, some Maven Projects 
and so on. So that is not really a problem for PHPStorm, but I can check it 
back with the IDE. I think one problem is, that I can have multiple projects 
open at the same time (of course there are a lot of benefits and I use it 
everyday). But when I can commit and push, why I need a background scanning? 
Because it was possible, but this action is holding in line.

I don't know the solution for that "problem" only to let everyone know, that 
this is a bottleneck. I have to wait a long range of time. I can open my 
command line and can push/pull w/o waiting. Of course there is no need to do 
anything else, but there shouldn't be nothing else before, when I can commit, 
pull, push from the IDE.


was (Author: chrizzly):
I don't know, I only use IntelliJ or WebStorm or PHPStorm to test smth but not 
hours. I switch back to NetBeans. So I have to try PHPStorm for our legacy PHP 
code base. Some versions ago, it was not really possible to open multiple 
projects which are independent from each other. So I have now 18 Projects in 
NetBeans open at the same time. 2 PHP, 1 is really big. 2 gradle projects, some 
HTML5 projects, some Maven Projects and so on. So that is not really a problem 
for PHPStorm, but I can check it back with the IDE. I think one problem is, 
that I can have multiple projects open at the same time (of course there are a 
lot of benefits and I use it everyday). But when I can commit and push, why I 
need a background scanning? Because it was possible, but this action is holding 
in line.

I don't know the solution for that "problem" only to let everyone know, that 
this is a bottleneck. I have to wait a long range of time. I can open my 
command line and can push/pull w/o waiting. Of course there is no need to do 
anything else, but there shouldn't be nothing else before, when I can commit, 
pull, push from the IDE.

> Background scanning process needs a rethink
> ---
>
> Key: NETBEANS-168
> URL: https://issues.apache.org/jira/browse/NETBEANS-168
> Project: NetBeans
>  Issue Type: Bug
>  Components: ide - Performance, java - Platform, platform - Execution
>Affects Versions: 8.2, Next
> Environment: NetBeans 8.2, Windows 10 x64
>Reporter: Christian Lenz
>Priority: Critical
>
> Often, while cloning, switching branch, merging, opening etc. etc. NetBeans 
> starts Background scanning for changes, but it is not real background, 
> because everything what you want to do then, like changing the branch, 
> commit, push, pull, open project, delete or whatever, is blocking by this 
> task and you can't cancel it, because it is essential.
> Either we need to rethink about this process like to make everything or most 
> of the stuff doing things in parallel or the task should really be 
> cancelable. It is a pain in the ass for big projects when they start to scan 
> for changes. 
> It is a real world case because you acan see it when you work on NetBeans 
> modules.
> Cheers
> Chris



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Comment Edited] (NETBEANS-168) Background scanning process needs a rethink

2019-02-15 Thread Christian Lenz (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16769134#comment-16769134
 ] 

Christian Lenz edited comment on NETBEANS-168 at 2/15/19 9:31 AM:
--

But again, it is not only about gradle. I don't use gradle at all.


was (Author: chrizzly):
But again, it is not only about gradle. I don't use gradle for example.

> Background scanning process needs a rethink
> ---
>
> Key: NETBEANS-168
> URL: https://issues.apache.org/jira/browse/NETBEANS-168
> Project: NetBeans
>  Issue Type: Bug
>  Components: ide - Performance, java - Platform, platform - Execution
>Affects Versions: 8.2, 9.0, 10.0
> Environment: NetBeans 8.2, Windows 10 x64
>Reporter: Christian Lenz
>Priority: Blocker
>  Labels: ca_survey, pull-request-available
> Attachments: go-to-file.gif, messages - 10.0 vc3.log, messages 10.0 
> vc2.log, messages.log, puls.7z, ui.log, uigestures 10.0 vc, wp-dms.7z
>
>  Time Spent: 3.5h
>  Remaining Estimate: 0h
>
> Often, while cloning, switching branch, merging, opening etc. etc. NetBeans 
> starts Background scanning for changes, but it is not real background, 
> because everything what you want to do then, like changing the branch, 
> commit, push, pull, open project, delete or whatever, is blocking by this 
> task and you can't cancel it, because it is essential.
> Either we need to rethink about this process like to make everything or most 
> of the stuff doing things in parallel or the task should really be 
> cancelable. It is a pain in the ass for big projects when they start to scan 
> for changes. 
> It is a real world case because you acan see it when you work on NetBeans 
> modules.
> Cheers
> Chris



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Comment Edited] (NETBEANS-168) Background scanning process needs a rethink

2018-12-27 Thread JIRA


[ 
https://issues.apache.org/jira/browse/NETBEANS-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16729581#comment-16729581
 ] 

Ivan Friedländer edited comment on NETBEANS-168 at 12/27/18 12:55 PM:
--

There are two problems:
The first is global and is in 
org.netbeans.modules.versioning.masterfs.FilesystemInterceptor.deletedExternally(FileObject
 fo)
It's called VCSFileProxy.createFileProxy(final FileObject fileObject) and that 
method registers a new listener.
It needs to be changed to 
VCSFilesystemInterceptor.deletedExternally(VCSFileProxy.createFileProxy(FileUtil.toFile(fo)));

And the other is about broken links in 
org.netbeans.modules.masterfs.filebasedfs.fileobjects.FileObjectFactory.issueIfExist(...)

{code:java}
 if (parent != null && parent.isValid()) {
if (child != null) {
if (foForFile == null) {
exist = (realExists == -1) ? true : touchExists(file, 
realExists);
if (fcb.impeachExistence(file, exist)) {
exist = touchExists(file, realExists);
if (!exist) {
refreshFromGetter(parent,asyncFire);
}
}
assert checkCacheState(true, file, caller);
} else if (foForFile.isValid()) {
exist = (realExists == -1) ? true : touchExists(file, 
realExists);
if (fcb.impeachExistence(file, exist)) {
exist = touchExists(file, realExists);
if (!exist) {
refreshFromGetter(parent,asyncFire);
}
}
assert checkCacheState(exist, file, caller);
} else {
//! inconsistence
exist = touchExists(file, realExists);
if (!exist) {
//Problematic test, for broken link is false
refreshFromGetter(parent,asyncFire);
}
}
} else {
{code}
if (!exist) { changed to if (!exist && !Files.isSymbolicLink(file.toPath())) {
And CPU has been quiet since then..
Attention change just this one line, I tried to move it into the method 
touchExists, but again it was the result Suspended

Details are here:
[https://github.com/NBANDROIDTEAM/NBANDROID-V2/issues/139]






was (Author: arsi):
There are two problems:
The first is global and is in 
org.netbeans.modules.versioning.masterfs.FilesystemInterceptor.deletedExternally(FileObject
 fo)
It's called VCSFileProxy.createFileProxy(final FileObject fileObject) and that 
method registers a new listener.
It needs to be changed to 
VCSFilesystemInterceptor.deletedExternally(VCSFileProxy.createFileProxy(FileUtil.toFile(fo)));

And the other is about broken links in 
org.netbeans.modules.masterfs.filebasedfs.fileobjects.FileObjectFactory.issueIfExist(...)

{code:java}
 if (parent != null && parent.isValid()) {
if (child != null) {
if (foForFile == null) {
exist = (realExists == -1) ? true : touchExists(file, 
realExists);
if (fcb.impeachExistence(file, exist)) {
exist = touchExists(file, realExists);
if (!exist) {
refreshFromGetter(parent,asyncFire);
}
}
assert checkCacheState(true, file, caller);
} else if (foForFile.isValid()) {
exist = (realExists == -1) ? true : touchExists(file, 
realExists);
if (fcb.impeachExistence(file, exist)) {
exist = touchExists(file, realExists);
if (!exist) {
refreshFromGetter(parent,asyncFire);
}
}
assert checkCacheState(exist, file, caller);
} else {
//! inconsistence
exist = touchExists(file, realExists);
if (!exist) {
//Problematic test, for broken link is false
refreshFromGetter(parent,asyncFire);
}
}
} else {
{code}
f (!exist) { changed to if (!exist && !Files.isSymbolicLink(file.toPath())) {
And CPU has been quiet since then..
Attention change just this one line, I tried to move it into the method 
touchExists, but again it was the result Suspended

Details are here:
[https://github.com/NBANDROIDTEAM/NBANDROID-V2/issues/139]





> Background scanning process needs a rethink
> ---
>
> Key: NETBEANS-168
> URL: https://issues.apache.org/jira/browse/NETBEANS-168
>

[jira] [Comment Edited] (NETBEANS-168) Background scanning process needs a rethink

2019-02-03 Thread Eric Bresie (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16759470#comment-16759470
 ] 

Eric Bresie edited comment on NETBEANS-168 at 2/3/19 4:45 PM:
--

Does this in any way relate to other background process/cpu issues like:
 # NETBEANS-1864 Background Scanning got stuck
 # NETBEANS-1939 Silent exception thrown during background scanning of projects
 # NETBEANS-1629 there is a memory overflow error when background scanning is 
going on, mainly for large projects/projects within projects or when there are 
many projects open
 # NETBEANS-1929 Hangs during the "Background scanning the projects" (resolved)
 # NETBEANS-1142 Exception when scanning projects
 # NETBEANS-1668 Netbeans Appears to Become Unresponsive
 # NETBEANS-1610 Constant background CPU usage
 # NETBEANS-485 OutOfMemoryError after background scanning of local Maven 
repository
 # NETBEANS-416 Excessive CPU usage


was (Author: ebresie):
Does this in any way relate to other background process/cpu issues like:
 # NETBEANS-1864 Background Scanning got stuck
 # NETBEANS-1939 Silent exception thrown during background scanning of projects
 # NETBEANS-1629 there is a memory overflow error when background scanning is 
going on, mainly for large projects/projects within projects or when there are 
many projects open
 # NETBEANS-1929 Hangs during the "Background scanning the projects" (resolved)
 # NETBEANS-1142 Exception when scanning projects
 # NETBEANS-1668 Netbeans Appears to Become Unresponsive
 # NETBEANS-1610 Constant background CPU usage
 # NETBEANS-485 OutOfMemoryError after background scanning of local Maven 
repository
 # NETBEANS-416 Excessive CPU usage
 #

> Background scanning process needs a rethink
> ---
>
> Key: NETBEANS-168
> URL: https://issues.apache.org/jira/browse/NETBEANS-168
> Project: NetBeans
>  Issue Type: Bug
>  Components: ide - Performance, java - Platform, platform - Execution
>Affects Versions: 8.2, 9.0, 10.0
> Environment: NetBeans 8.2, Windows 10 x64
>Reporter: Christian Lenz
>Priority: Blocker
>  Labels: ca_survey, pull-request-available
> Attachments: go-to-file.gif, messages - 10.0 vc3.log, messages 10.0 
> vc2.log, messages.log, puls.7z, ui.log, uigestures 10.0 vc, wp-dms.7z
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> Often, while cloning, switching branch, merging, opening etc. etc. NetBeans 
> starts Background scanning for changes, but it is not real background, 
> because everything what you want to do then, like changing the branch, 
> commit, push, pull, open project, delete or whatever, is blocking by this 
> task and you can't cancel it, because it is essential.
> Either we need to rethink about this process like to make everything or most 
> of the stuff doing things in parallel or the task should really be 
> cancelable. It is a pain in the ass for big projects when they start to scan 
> for changes. 
> It is a real world case because you acan see it when you work on NetBeans 
> modules.
> Cheers
> Chris



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Comment Edited] (NETBEANS-168) Background scanning process needs a rethink

2018-08-22 Thread Gilberto C Andrade (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16589041#comment-16589041
 ] 

Gilberto C Andrade edited comment on NETBEANS-168 at 8/22/18 3:46 PM:
--

Just clone the incubator-netbeans project and open it(some modules only) with 
Netbeans, you will see the behavior [~Chrizzly] is talking about.


was (Author: gilbertoca):
Just clone the incubator-netbeans project and open it with Netbeans, you will 
see the behavior [~Chrizzly] is talking about.

> Background scanning process needs a rethink
> ---
>
> Key: NETBEANS-168
> URL: https://issues.apache.org/jira/browse/NETBEANS-168
> Project: NetBeans
>  Issue Type: Bug
>  Components: ide - Performance, java - Platform, platform - Execution
>Affects Versions: 8.2, Next
> Environment: NetBeans 8.2, Windows 10 x64
>Reporter: Christian Lenz
>Priority: Critical
>
> Often, while cloning, switching branch, merging, opening etc. etc. NetBeans 
> starts Background scanning for changes, but it is not real background, 
> because everything what you want to do then, like changing the branch, 
> commit, push, pull, open project, delete or whatever, is blocking by this 
> task and you can't cancel it, because it is essential.
> Either we need to rethink about this process like to make everything or most 
> of the stuff doing things in parallel or the task should really be 
> cancelable. It is a pain in the ass for big projects when they start to scan 
> for changes. 
> It is a real world case because you acan see it when you work on NetBeans 
> modules.
> Cheers
> Chris



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Comment Edited] (NETBEANS-168) Background scanning process needs a rethink

2018-10-31 Thread Christian Lenz (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16670694#comment-16670694
 ] 

Christian Lenz edited comment on NETBEANS-168 at 10/31/18 8:45 PM:
---

Hope it is now enough to figure out what's wrong. It seems that the indexing is 
taking to much time.


was (Author: chrizzly):
Hope it is now enough to figure out what's wrong. It seems that the indexing is 
taking to much.

> Background scanning process needs a rethink
> ---
>
> Key: NETBEANS-168
> URL: https://issues.apache.org/jira/browse/NETBEANS-168
> Project: NetBeans
>  Issue Type: Bug
>  Components: ide - Performance, java - Platform, platform - Execution
>Affects Versions: 8.2, Next
> Environment: NetBeans 8.2, Windows 10 x64
>Reporter: Christian Lenz
>Priority: Critical
> Attachments: messages 10.0 vc2.log, messages.log, ui.log, uigestures 
> 10.0 vc
>
>
> Often, while cloning, switching branch, merging, opening etc. etc. NetBeans 
> starts Background scanning for changes, but it is not real background, 
> because everything what you want to do then, like changing the branch, 
> commit, push, pull, open project, delete or whatever, is blocking by this 
> task and you can't cancel it, because it is essential.
> Either we need to rethink about this process like to make everything or most 
> of the stuff doing things in parallel or the task should really be 
> cancelable. It is a pain in the ass for big projects when they start to scan 
> for changes. 
> It is a real world case because you acan see it when you work on NetBeans 
> modules.
> Cheers
> Chris



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Comment Edited] (NETBEANS-168) Background scanning process needs a rethink

2018-12-18 Thread flexJoly (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16723949#comment-16723949
 ] 

flexJoly edited comment on NETBEANS-168 at 12/18/18 11:27 AM:
--

This morning I installed v10-rc5 for windows. It runs nice at first. But my 
(framework) php-project keeps scanned forever It does not hang netbeans. 
But it holds at a certain percentage. At the moment it is 25% after restarting 
netbeans. Before it came to 75% and 85% (between restarts).

 

update:
after about half an hour it is getting to 100% and autocomplete for php gets 
working better


was (Author: flexjoly):
This morning I installed v10-rc5 for windows. It runs nice at first. But my 
(framework) php-project keeps scanned forever It does not hang netbeans. 
But it holds at a certain percentage. At the moment it is 25% after restarting 
netbeans. Before it came to 75% and 85% (between restarts).

> Background scanning process needs a rethink
> ---
>
> Key: NETBEANS-168
> URL: https://issues.apache.org/jira/browse/NETBEANS-168
> Project: NetBeans
>  Issue Type: Bug
>  Components: ide - Performance, java - Platform, platform - Execution
>Affects Versions: 8.2, 9.0, 10.0
> Environment: NetBeans 8.2, Windows 10 x64
>Reporter: Christian Lenz
>Priority: Critical
>  Labels: ca_survey
> Attachments: go-to-file.gif, messages - 10.0 vc3.log, messages 10.0 
> vc2.log, messages.log, puls.7z, ui.log, uigestures 10.0 vc, wp-dms.7z
>
>
> Often, while cloning, switching branch, merging, opening etc. etc. NetBeans 
> starts Background scanning for changes, but it is not real background, 
> because everything what you want to do then, like changing the branch, 
> commit, push, pull, open project, delete or whatever, is blocking by this 
> task and you can't cancel it, because it is essential.
> Either we need to rethink about this process like to make everything or most 
> of the stuff doing things in parallel or the task should really be 
> cancelable. It is a pain in the ass for big projects when they start to scan 
> for changes. 
> It is a real world case because you acan see it when you work on NetBeans 
> modules.
> Cheers
> Chris



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists