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

Provide a way to get session size #23

Open
pdeva opened this issue Jul 19, 2014 · 10 comments
Open

Provide a way to get session size #23

pdeva opened this issue Jul 19, 2014 · 10 comments
Labels
status: waiting-for-triage An issue we've not yet triaged

Comments

@pdeva
Copy link

pdeva commented Jul 19, 2014

.. Using a JMX metric ideally. Very useful when you want to make sure the session size doesn't go out of hand when using frameworks like Vaadin or gwt

@solidjb
Copy link

solidjb commented Apr 21, 2015

Here are the bean attributes that Jetty exposes with its nosql session manager. I believe Spring Session should support a similar set.

screen shot 2015-04-21 at 10 08 54 am

Jetty's nosql session support uses mongodb and not redis, but these values do not seem mongo-centric. The mongo-centric beans are separate.

The values above are provided from http://download.eclipse.org/jetty/stable-9/apidocs/org/eclipse/jetty/server/session/AbstractSessionManager.html

@cmhdave
Copy link

cmhdave commented Jan 12, 2016

+1

1 similar comment
@overWired
Copy link

+1

@chrylis
Copy link
Contributor

chrylis commented Jan 12, 2016

I may be overlooking something obvious here, but what exactly is the "size" of a session?

@solidjb
Copy link

solidjb commented May 31, 2016

Question for the project maintainers. Would there be an objection to creating an implementation of SessionRepository that uses a DropWizard Counter and DropWizard Histogram to provide stats similar to what Jetty does? (see my previous Post)

I am curious if there is a philosophical problem with adding the dependency on DropWizard.

@rwinch
Copy link
Member

rwinch commented May 31, 2016

@solidjb I don't know a lot about these portions of DropWizzard so it is hard to say definitively. Practically speaking, we are open to adding new dependencies so long as they are part of Spring IO Platform (as we must be Spring IO compliant) and they are optional.

@solidjb
Copy link

solidjb commented May 31, 2016

I am still working on the testing, but the class itself is pretty simple.

package org.springframework.session.dropwizard;

import static java.lang.Math.round;

import com.codahale.metrics.Counter;
import com.codahale.metrics.Histogram;
import org.springframework.session.ExpiringSession;
import org.springframework.session.SessionRepository;

/**
 * This class will use dropwizard metrics to record statistics about the number of sessions and their durations.
 */
public class DropWizardMetricsRecordingSessionRepository implements SessionRepository<ExpiringSession> {

    private final SessionRepository<ExpiringSession> repository;

    private final Counter sessionCountingStats;
    private final Histogram sessionTimingStats;

    public DropWizardMetricsRecordingSessionRepository(
            SessionRepository<ExpiringSession> repository,
            Counter sessionCountingStats,
            Histogram sessionTimingStats
    ) {
        this.repository = repository;
        this.sessionCountingStats = sessionCountingStats;
        this.sessionTimingStats = sessionTimingStats;
    }

    @Override
    public ExpiringSession createSession() {
        final ExpiringSession createdSession = repository.createSession();

        sessionCountingStats.inc();

        return createdSession;
    }

    @Override
    public void save(ExpiringSession session) {
        repository.save(session);
    }

    @Override
    public ExpiringSession getSession(String id) {
        return repository.getSession(id);
    }

    @Override
    public void delete(String id) {

        final ExpiringSession session = getSession(id);

        repository.delete(id);

        sessionCountingStats.dec();

        if (session != null) {
            sessionTimingStats.update(calculateSessionDuration(session));
        }
    }

    private long calculateSessionDuration(ExpiringSession session) {
        return round((System.currentTimeMillis() - session.getCreationTime()) / 1000.0);
    }
}

What do you think?

@solidjb
Copy link

solidjb commented May 31, 2016

The above code would only have the following dependencies:

dependencies {
    compile (
            libraries.dropWizardCore,
            libraries.springSession,
    )

    testCompile (
            libraries.mockitoCore
    )
}

I think that meets your criteria. When I am done with the tests, can I create a pull request?

@rwinch
Copy link
Member

rwinch commented May 31, 2016

@solidjb Thanks for the reply. The dependencies look like it will work. However, the implementation looks like it lacks support for handling an expired session. Can you create a new ticket that we can use to discuss this (since this does not appear to address this specific issue).

@solidjb
Copy link

solidjb commented May 31, 2016

Done - #535

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label May 23, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: waiting-for-triage An issue we've not yet triaged
Projects
None yet
Development

No branches or pull requests

7 participants