Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 611846 - Test bundle subsystem with large bundles
Test bundle subsystem with large bundles
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Content (Show other bugs)
unspecified
All All
urgent Severity medium (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
Filip Drabek
:
Depends On:
Blocks: jon-sprint12-bugs
  Show dependency treegraph
 
Reported: 2010-07-06 12:37 EDT by Charles Crouch
Modified: 2015-02-01 18:26 EST (History)
4 users (show)

See Also:
Fixed In Version: 2.4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-12 12:54:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Charles Crouch 2010-07-06 12:37:05 EDT
We need to make sure that no part of the bundle system is susceptible to problems due to large bundle files:

Couple of areas we need to test 
1) No OOM errors on agent or server, basically that we don't read the whole bundle file into memory while processing it, this applies to both server and agent
2) Database txn timeouts, make sure that if an upload of a bundle or download of a bundle to an agent takes a long time, due to it being large or the link being slow that we don't end up with a txn timeout, e.g. after 10mins

Test cases
1)
a) Upload a 1gb bundle using all of the various upload mechanisms
b) Install 1gb bundle on an agent

2)
a) Upload a 1gb bundle using all of the various upload mechanisms, where the source of the bundle (url, browser) does not share a fast network with the JON server, e.g. browser upload from laptop to RH based jon server, RH url upload to laptop based jon server
b) Install 1gb bundle on an agent which does not share a fast network with the JON server
Comment 1 Charles Crouch 2010-07-09 12:39:37 EDT
Setting directly to ON_QA
Comment 2 Jay Shaughnessy 2010-07-09 13:44:24 EDT
Note: to really test a huge file going from server to agent then what is important is that you have a large file in the distribution, not just a large distribution file. This is because each bundle file will be dragged over individually.  Meaning, the 1G distribution zip would need to contain probably 1 huge bundle file (maybe a zip of like 3 EAPs or something :) and the recipe file.
Comment 3 Filip Drabek 2010-07-14 16:24:21 EDT
I have 1GB file to upload via web. 
After 3 minutes I'm getting this exception:
HTTP Status 500 -

org.rhq.enterprise.server.auth.SessionNotFoundException
	org.rhq.enterprise.server.auth.SessionManager.getSubject(SessionManager.java:167)
	org.rhq.enterprise.server.auth.SubjectManagerBean.getSubjectBySessionId(SubjectManagerBean.java:568)
	sun.reflect.GeneratedMethodAccessor993.invoke(Unknown Source)
	sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	java.lang.reflect.Method.invoke(Method.java:597)

Content is loaded to RAM (increase about 870MB).
Comment 4 Jay Shaughnessy 2010-07-15 16:58:33 EDT
I'm fairly sure this large-bundle load failure is not a bug but probably a manifestation of our shared session id behavior.  Make sure you absolutely don't have any other rhq browser windows open. Restart the server, start a gui portal war session, nav to bundles and try the upload.

If the coregui has a valid sessionid this issue does not appear for me no matter what size bundle I use.  If I invalidate the user's session I can recreate it with any size bundle.  (note - to invalidate the session: in another browser tab log into a new gui session as the same user, then log out of it. Then, go back to your bundle test tab, it's session is now invalid.)  

Assuming the upload now works the test can continue.
Comment 5 Jay Shaughnessy 2010-07-15 17:33:17 EDT
I was able to deploy a bundle with a bundle file ~850MB. It wasn't fast, the streaming into and out of the db is a bit cumbersome, but it succeeded.
Comment 6 Filip Drabek 2010-07-19 08:22:28 EDT
When bundle site is opened and there is no activity for 30 minutes the session is invalidated, but because there is no callback to server and no data to show when you open the bundle site for first time you will not recognize that your session is invalidate. When you want to create a new bundle with already invalidate session the window will be opened because it is javascript code without callback to server and when you will choose file and click on button 'Next', uploading will be processed and when 100% is uploaded you will get message: HTTP Status 500 -javax.servlet.ServletException: Cannot authenticate request, org.rhq.enterprise.server.auth.SessionNotFoundException.
Comment 7 Corey Welton 2010-07-20 16:14:38 EDT
Closing this one out, following testing.  Dev will open a separate bz on the timeout issue.
Comment 8 Corey Welton 2010-08-12 12:54:47 EDT
Mass-closure of verified bugs against JON.

Note You need to log in before you can comment on or make changes to this bug.