Howdy, few days ago Sonatype released Nexus 1.9, having one of the "biggest" change in relation to security: finally updating from JSecurity 0.9-RC2 to Shiro 1.0-incubating.
It seemed all fine, but some behavior did change -- I have to emphasize: it's not Shiro, but our "glue" (business logic) code to be blamed -- the Sessions started behaving differently. Nexus has REST Resources only (does not have UI, the UI is actually a "standalone" JS application communicating over REST with Nexus), hence, no state needed on Nexus side. But still, as we know, Shiro always creates Sessions, and as it turned out, on heavily loaded systems, they would not be cleaned up it timely fashion (yes, all was working nice, but the load was higher than timeouts were occurring). Here is an issue, where it's obvious that a Map of Shiro's SimpleSession "eats" up the memory of Nexus: https://issues.sonatype.org/browse/NEXUS-4118 I read some on this mailing least about Shiro + REST + session-less mode, but concluded that Shiro 1.0-incubating does not offer out-of-the-box solution for this. Later, I found something I believe is related: https://issues.apache.org/jira/browse/SHIRO-266 But is scheduled for Shiro 1.2.0.... bummer. So, finally the "fix" (quickfix, circumvention, call it as you like) I ended up was this: https://sventon.sonatype.org/repos/nexus-oss/info?revision=7850 Simply, at the end of processing (filtering), we log out the subject always. And it works fine for us. The culprit was actually "simple" clients, that connect a lot and in burst to nexus: Maven, wget, ant, etc, that does not pass over cookies (are also stateless!), and one artifact request from maven (which boils down to 4 HTTP requests: POM, JAR and SHA1 files for both of them) resulted in 4 session creation. And in case above (NEXUS-4118), it is a highly loaded instance, so it received a "huge burst" of download requests, when it cracked. Simply, the session cleanup was not being able to catch up. I just wanted to share this with you guys, and ask for opinions. Les proposed some alternative solution in comments of NEXUS-4118 too. -- And finally, we are about to release Nexus 1.9.0.1 to address this issue ;) Thanks, ~t~
