maintenance_gem.log expired sessions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

maintenance_gem.log expired sessions

GLASS mailing list
Ciao,
i have a deployment glass environment system ( 3.1.0.6 )

where i run the Seaside maintenance VM.

Now the  maintenance_gem.log  report:

hourly :

--transcript--'Starting markForCollect.: 2015-12-06T03:35:11.58872890472412+01:00' --transcript--'Warning: markForCollection found 2569174 live objects, 4553 dead objects(occupying approx 409770 bytes)' --transcript--'...finished markForCollect.2015-12-06T03:35:19.36173295974731+01:00'
every minute:

...Expired: 0 sessions.
...Expired: 20 sessions.
...Expired: 4 sessions.
...Expired: 9 sessions.
...Expired: 3 sessions.
...Expired: 0 sessions.
...Expired: 0 sessions.
...Expired: 0 sessions.
...Expired: 0 sessions.


Now my application open only two local session  ( DTRWASession  subclass of WASession ) every day.

Where for local i intend on the local network where the Glass server run.

 I don't understand  because the maintenance report some other Expired session.

The maintenance expired session reference to WASession open  or reference- mean to some other thinks?

The system records information about the WASession open and the relative IP request  address   ?

Sessions expired can be related to intrusion attempts from internet?


Thanks for considerations,

Dario


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: maintenance_gem.log expired sessions

GLASS mailing list


On Wed, Dec 9, 2015 at 8:20 AM, Trussardi Dario Romano via Glass <[hidden email]> wrote:
Ciao,
i have a deployment glass environment system ( 3.1.0.6 )

where i run the Seaside maintenance VM.

Now the  maintenance_gem.log  report:

hourly :

--transcript--'Starting markForCollect.: 2015-12-06T03:35:11.58872890472412+01:00' --transcript--'Warning: markForCollection found 2569174 live objects, 4553 dead objects(occupying approx 409770 bytes)' --transcript--'...finished markForCollect.2015-12-06T03:35:19.36173295974731+01:00'
every minute:

...Expired: 0 sessions.
...Expired: 20 sessions.
...Expired: 4 sessions.
...Expired: 9 sessions.
...Expired: 3 sessions.
...Expired: 0 sessions.
...Expired: 0 sessions.
...Expired: 0 sessions.
...Expired: 0 sessions.


Now my application open only two local session  ( DTRWASession  subclass of WASession ) every day.

Where for local i intend on the local network where the Glass server run.

 I don't understand  because the maintenance report some other Expired session.

The maintenance expired session reference to WASession open  or reference- mean to some other thinks?

The system records information about the WASession open and the relative IP request  address   ?

Sessions expired can be related to intrusion attempts from internet?



Yes, that looks strange. If you check the object log entries (either via tODE command "ol view -r"  or from WAObjectLog) you can see the timestamp.
So...if you are sure nobody was doing anything at all at that time then it might be intrusion attempts. Bear in mind the session timeout. 
I wonder if you have some kind of service that would do a HTTP GET over the main URL for checking sanity of the system (kind of monit tool)?
 
Thanks for considerations,

Dario


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: maintenance_gem.log expired sessions

GLASS mailing list



On Wed, Dec 9, 2015 at 8:20 AM, Trussardi Dario Romano via Glass <[hidden email]> wrote:
Ciao,
i have a deployment glass environment system ( 3.1.0.6 )

where i run the Seaside maintenance VM.

Now the  maintenance_gem.log  report:

hourly :

--transcript--'Starting markForCollect.: 2015-12-06T03:35:11.58872890472412+01:00' --transcript--'Warning: markForCollection found 2569174 live objects, 4553 dead objects(occupying approx 409770 bytes)' --transcript--'...finished markForCollect.2015-12-06T03:35:19.36173295974731+01:00'
every minute:

...Expired: 0 sessions.
...Expired: 20 sessions.
...Expired: 4 sessions.
...Expired: 9 sessions.
...Expired: 3 sessions.
...Expired: 0 sessions.
...Expired: 0 sessions.
...Expired: 0 sessions.
...Expired: 0 sessions.


Now my application open only two local session  ( DTRWASession  subclass of WASession ) every day.

Where for local i intend on the local network where the Glass server run.

 I don't understand  because the maintenance report some other Expired session.

The maintenance expired session reference to WASession open  or reference- mean to some other thinks?

The system records information about the WASession open and the relative IP request  address   ?

Sessions expired can be related to intrusion attempts from internet?



Yes, that looks strange. If you check the object log entries (either via tODE command "ol view -r"  or from WAObjectLog) you can see the timestamp.
So...if you are sure nobody was doing anything at all at that time then it might be intrusion attempts. Bear in mind the session timeout. 
I wonder if you have some kind of service that would do a HTTP GET over the main URL for checking sanity of the system (kind of monit tool)?

Ciao Mariano,
i have the following services ( launched by daemontools ) :

/etc/service/gs_maintenance: up (pid 11242) 2221972 seconds

/etc/service/gs_seaside-9060: up (pid 11240) 2221972 seconds

/etc/service/gs_seaside-9061: up (pid 11244) 2221972 seconds

/etc/service/gs_seaside-9062: up (pid 11245) 2221972 seconds

/etc/service/gs_seaside-9063: up (pid 11247) 2221972 seconds

/etc/service/gs_seaside-9064: up (pid 11246) 2221972 seconds

/etc/service/gs_seaside-9065: up (pid 11248) 2221972 seconds

/etc/service/gs_statmon-1: up (pid 11241) 2221972 seconds

/etc/service/gs_statmon-60: up (pid 11243) 2221972 seconds


The gs_statmon-x  services open some sessions in the server ?

Thanks,

Dario




_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: maintenance_gem.log expired sessions

GLASS mailing list
Dario,

Are you using AJAX calls in some parts of your app -- depending upon how the calls are made, you might get several sessions spun up from a single http request ...

If you are concerned you could go into the session expiry logic and record additional information in the object log about the sessions that are being expired ... with such a low volume of requests, you could probably afford to grab a days worth of sessions without expiring them and open in an inspector to see exactly what's going on ...


Dale



On 12/9/15 5:20 AM, Trussardi Dario Romano via Glass wrote:



On Wed, Dec 9, 2015 at 8:20 AM, Trussardi Dario Romano via Glass <[hidden email]> wrote:
Ciao,
i have a deployment glass environment system ( 3.1.0.6 )

where i run the Seaside maintenance VM.

Now the  maintenance_gem.log  report:

hourly :

--transcript--'Starting markForCollect.: 2015-12-06T03:35:11.58872890472412+01:00' --transcript--'Warning: markForCollection found 2569174 live objects, 4553 dead objects(occupying approx 409770 bytes)' --transcript--'...finished markForCollect.2015-12-06T03:35:19.36173295974731+01:00'
every minute:

...Expired: 0 sessions.
...Expired: 20 sessions.
...Expired: 4 sessions.
...Expired: 9 sessions.
...Expired: 3 sessions.
...Expired: 0 sessions.
...Expired: 0 sessions.
...Expired: 0 sessions.
...Expired: 0 sessions.


Now my application open only two local session  ( DTRWASession  subclass of WASession ) every day.

Where for local i intend on the local network where the Glass server run.

 I don't understand  because the maintenance report some other Expired session.

The maintenance expired session reference to WASession open  or reference- mean to some other thinks?

The system records information about the WASession open and the relative IP request  address   ?

Sessions expired can be related to intrusion attempts from internet?



Yes, that looks strange. If you check the object log entries (either via tODE command "ol view -r"  or from WAObjectLog) you can see the timestamp.
So...if you are sure nobody was doing anything at all at that time then it might be intrusion attempts. Bear in mind the session timeout. 
I wonder if you have some kind of service that would do a HTTP GET over the main URL for checking sanity of the system (kind of monit tool)?

Ciao Mariano,
i have the following services ( launched by daemontools ) :

/etc/service/gs_maintenance: up (pid 11242) 2221972 seconds

/etc/service/gs_seaside-9060: up (pid 11240) 2221972 seconds

/etc/service/gs_seaside-9061: up (pid 11244) 2221972 seconds

/etc/service/gs_seaside-9062: up (pid 11245) 2221972 seconds

/etc/service/gs_seaside-9063: up (pid 11247) 2221972 seconds

/etc/service/gs_seaside-9064: up (pid 11246) 2221972 seconds

/etc/service/gs_seaside-9065: up (pid 11248) 2221972 seconds

/etc/service/gs_statmon-1: up (pid 11241) 2221972 seconds

/etc/service/gs_statmon-60: up (pid 11243) 2221972 seconds


The gs_statmon-x  services open some sessions in the server ?

Thanks,

Dario





_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: maintenance_gem.log expired sessions

GLASS mailing list


On Wed, Dec 9, 2015 at 8:34 PM, Dale Henrichs via Glass <[hidden email]> wrote:
Dario,

Are you using AJAX calls in some parts of your app -- depending upon how the calls are made, you might get several sessions spun up from a single http request ...


Dale, in which case an AJAX call would get several sessions spun up from a single http request?


 
If you are concerned you could go into the session expiry logic and record additional information in the object log about the sessions that are being expired ... with such a low volume of requests, you could probably afford to grab a days worth of sessions without expiring them and open in an inspector to see exactly what's going on ...


Dale




On 12/9/15 5:20 AM, Trussardi Dario Romano via Glass wrote:



On Wed, Dec 9, 2015 at 8:20 AM, Trussardi Dario Romano via Glass <[hidden email][hidden email]> wrote:
Ciao,
i have a deployment glass environment system ( 3.1.0.6 )

where i run the Seaside maintenance VM.

Now the  maintenance_gem.log  report:

hourly :

--transcript--'Starting markForCollect.: 2015-12-06T03:35:11.58872890472412+01:00' --transcript--'Warning: markForCollection found 2569174 live objects, 4553 dead objects(occupying approx 409770 bytes)' --transcript--'...finished markForCollect.2015-12-06T03:35:19.36173295974731+01:00'
every minute:

...Expired: 0 sessions.
...Expired: 20 sessions.
...Expired: 4 sessions.
...Expired: 9 sessions.
...Expired: 3 sessions.
...Expired: 0 sessions.
...Expired: 0 sessions.
...Expired: 0 sessions.
...Expired: 0 sessions.


Now my application open only two local session  ( DTRWASession  subclass of WASession ) every day.

Where for local i intend on the local network where the Glass server run.

 I don't understand  because the maintenance report some other Expired session.

The maintenance expired session reference to WASession open  or reference- mean to some other thinks?

The system records information about the WASession open and the relative IP request  address   ?

Sessions expired can be related to intrusion attempts from internet?



Yes, that looks strange. If you check the object log entries (either via tODE command "ol view -r"  or from WAObjectLog) you can see the timestamp.
So...if you are sure nobody was doing anything at all at that time then it might be intrusion attempts. Bear in mind the session timeout. 
I wonder if you have some kind of service that would do a HTTP GET over the main URL for checking sanity of the system (kind of monit tool)?

Ciao Mariano,
i have the following services ( launched by daemontools ) :

/etc/service/gs_maintenance: up (pid 11242) 2221972 seconds

/etc/service/gs_seaside-9060: up (pid 11240) 2221972 seconds

/etc/service/gs_seaside-9061: up (pid 11244) 2221972 seconds

/etc/service/gs_seaside-9062: up (pid 11245) 2221972 seconds

/etc/service/gs_seaside-9063: up (pid 11247) 2221972 seconds

/etc/service/gs_seaside-9064: up (pid 11246) 2221972 seconds

/etc/service/gs_seaside-9065: up (pid 11248) 2221972 seconds

/etc/service/gs_statmon-1: up (pid 11241) 2221972 seconds

/etc/service/gs_statmon-60: up (pid 11243) 2221972 seconds


The gs_statmon-x  services open some sessions in the server ?

Thanks,

Dario





_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: maintenance_gem.log expired sessions

GLASS mailing list


On 12/09/2015 03:39 PM, Mariano Martinez Peck wrote:


On Wed, Dec 9, 2015 at 8:34 PM, Dale Henrichs via Glass <[hidden email]> wrote:
Dario,

Are you using AJAX calls in some parts of your app -- depending upon how the calls are made, you might get several sessions spun up from a single http request ...


Dale, in which case an AJAX call would get several sessions spun up from a single http request?


Well I've never been that familiar with the AJAX mechanism, but I understood that there were cases where concurrent AJAX could be performed, implying separate sessions and cases where one needed to route AJAX requests to the same gem to avoid excessive retries ... I could easily be mistaken there...

BUT, looking at the code for the "expired session count" in WABasicDevelopment class>>reapHandlerCache:dispatchers: and WACache>>gemstoneReap the count is actually a count of the number of objects removed from the WAApplication>>cache and the WASession>continuations WACache instances, so that count has never been a count of the "number of sessions expired" ... That label has been wrong for the last 8 years:)

Dale

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass