Bug 571985 - Install from marketplace hangs and cannot be canceled
Summary: Install from marketplace hangs and cannot be canceled
Status: REOPENED
Alias: None
Product: MPC
Classification: Technology
Component: wizard (show other bugs)
Version: 1.9.0   Edit
Hardware: PC Windows 10
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-03-16 06:55 EDT by Wim Jongman CLA
Modified: 2021-03-16 16:11 EDT (History)
1 user (show)

See Also:


Attachments
Visual (29.61 KB, image/png)
2021-03-16 06:55 EDT, Wim Jongman CLA
no flags Details
mpc httpclient initialization error (9.98 KB, text/plain)
2021-03-16 08:20 EDT, Wim Jongman CLA
no flags Details
A project to provoke the issue (17.14 KB, application/x-zip-compressed)
2021-03-16 16:11 EDT, Wim Jongman CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Wim Jongman CLA 2021-03-16 06:55:31 EDT
Created attachment 285850 [details]
Visual

Install from marketplace hangs and cannot be canceled. This started yesterday.

I used different Eclipse installations on different networks.

Strangely, the URL is HTTP and not https. The website works fine, also with http
Comment 1 Wim Jongman CLA 2021-03-16 07:02:55 EDT
Pressing cancel in the dialog does nothing. That should be a minimal requirement for this dialog. 

Also, disconnecting from the network does not force the dialog to error out. I have to forcefully kill the process.
Comment 2 Wim Jongman CLA 2021-03-16 07:28:04 EDT
I am currently debugging the process. Before you reset any servers, give me 15 minutes to find out where it fails.
Comment 3 Wim Jongman CLA 2021-03-16 07:34:39 EDT
Ok, there is a blocking io going on from which we never return.

Thread [ModalContext] (Suspended)	
	owns: BufferedInputStream  (id=266)	
	waiting for: PipedInputStream  (id=267)	
	Object.wait(long, int) line: not available [native method]	
	PipedInputStream(Object).wait(long) line: 221	
	PipedInputStream.read() line: 326	
	PipedInputStream.read(byte[], int, int) line: 377	
	FileReader$1.read(byte[], int, int) line: 332	
	BufferedInputStream.fill() line: 252	
	BufferedInputStream.read1(byte[], int, int) line: 292	
	BufferedInputStream.read(byte[], int, int) line: 351	
	BufferedInputStream(FilterInputStream).read(byte[]) line: 107	
	FallbackTransportFactory$FallbackTransport.tryBuffer(BufferedInputStream) line: 119	
	FallbackTransportFactory$FallbackTransport.primaryFailed(URI, IProgressMonitor, Exception) line: 133	
	FallbackTransportFactory$FallbackTransport.stream(URI, IProgressMonitor) line: 97	
	DefaultCatalogService(RemoteMarketplaceService<T>).processRequest(String, String, boolean, IProgressMonitor) line: 165	
	DefaultCatalogService(RemoteMarketplaceService<T>).processRequest(String, boolean, IProgressMonitor) line: 130	
	DefaultCatalogService(RemoteMarketplaceService<T>).processRequest(String, IProgressMonitor) line: 117	
	DefaultCatalogService.listCatalogs(IProgressMonitor) line: 53	
	AbstractMarketplaceWizardCommand.lambda$0(AtomicReference, IProgressMonitor) line: 169	
	0000000000000000.run(IProgressMonitor) line: not available	
	ModalContext$ModalContextThread.run() line: 122
Comment 4 Wim Jongman CLA 2021-03-16 08:20:31 EDT
Created attachment 285853 [details]
mpc httpclient initialization error

The issue is caused by an httpclientservice implementation issue
Comment 5 Wim Jongman CLA 2021-03-16 09:54:53 EDT
Right. It was caused by a faulty user-installed plugin that exported the wrong version of o.a.commons.logging.

All httpclient related code was upset by this change (which in turn was used by mpc, git, p2, etc..). 

The code is not robust enough to handle this break (missing commons-logging) but ultimately it was not Eclipse.
Comment 6 Carsten Reckord CLA 2021-03-16 15:47:54 EDT
Hey Wim,

thanks for the detailed analysis and your conclusion. 

However, I'm thinking, since we maintain our OSGi bundling for the httpclient library ourselves in Orbit, if we can't do a better job of expressing our expected version of o.a.commons.logging so this doesn't happen (or at least breaks early and visibly).

To that end, can you say which plugin (+version) caused the breakage, or how it specified its of o.a.commons.logging export?
Comment 7 Carsten Reckord CLA 2021-03-16 15:48:58 EDT
Also, I think the MPC dialog should do a better job at degrading / failing instead of blocking the dialog. So I'm going to reopen and move this to the MPC project if you don't mind.
Comment 8 Carsten Reckord CLA 2021-03-16 15:51:29 EDT
Reopened as MPC bug
Comment 9 Wim Jongman CLA 2021-03-16 16:11:56 EDT
Created attachment 285858 [details]
A project to provoke the issue

(In reply to Carsten Reckord from comment #7)
> Also, I think the MPC dialog should do a better job at degrading / failing
> instead of blocking the dialog. So I'm going to reopen and move this to the
> MPC project if you don't mind.

No, brilliant. Let me write up the complete issue now I have still everything fresh. 

The issue was caused by a plugin that stated to export org.apache.commons.logging 1.7.5 but that jar actually contains commons.logging 1.1.1

I could see in the run configuration that there were issues, and it may be exceptional,  but it should not lockup Eclipse.

To duplicate:

set a breakpoint in FallbackTransportFactory 74 (a breakpoint file with all the nice landmarks is in the project :)

1. Restore the attached bundle
2. include it in a plain eclipse (with mpc)
3. Run with this bundle (you see httpclient and other bundlers complaining)
4. Start Marketplace from the menu

Eventually there is a NPE from httpclient which causes a jump into line 97 of FallbackTransportFactory. 

Stepping into primaryFailed you will see that tryBuffer method will block forever.