You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Alex O'Ree <al...@apache.org> on 2018/07/01 11:48:22 UTC
Requirements for servlet session attributes?
I was working on attempting to increase performance on a web app which
calls a jaxws service on behalf of the user. The process for creating the
jaxws client is somewhat slow so I was to try and cache the the jaxws
client object as an HTTP session attribute. It doesn't work for some reason.
What does work is attaching the jaxws client object to the application
context, however this isn't a feasible solution.
I vaguely recall running into a similar problem with performing the same
task in jboss which i think had the requirement for adding a @Serializable
annotation to anything added to the session object. Does tomcat require the
same?
Re: Requirements for servlet session attributes?
Posted by Luis RodrÃguez Fernández <uo...@gmail.com>.
Hello Alex,
It looks like you are missing the getSession() method there:
HttpServletRequest#getSession()#setAttribute("mykey", clientObjectHere);
please have a look at [1]
Hope it helps,
Luis
[1]
https://tomcat.apache.org/tomcat-9.0-doc/servletapi/javax/servlet/http/HttpServletRequest.html#getSession--
2018-07-03 23:28 GMT+02:00 Alex O'Ree <sp...@gmail.com>:
> The jaws client maybe takes 100ms to fire up. So it's not terrible slow
> but the overall website is noticeably faster when caching it. All of the
> resources (wsdls, xsds) are local but there's a quite a few of them.
>
> Caching this object does not work as a session attribute.
> HttpServletRequest#setAttribute("mykey", clientObjectHere);
> followed by
> HttpServletRequest#getAttribute("mykey") == null on subsequent http
> requests.
>
> ServletContext#setAttribute and getAttribute does work however it is not
> viable in my situation
>
>
> On Jul 1, 2018 9:43 AM, "Christopher Schultz" <
> chris@christopherschultz.net>
> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Alex,
>
>
> On 7/1/18 7:48 AM, Alex O'Ree wrote:
> > I was working on attempting to increase performance on a web app
> > which calls a jaxws service on behalf of the user. The process for
> > creating the jaxws client is somewhat slow so I was to try and
> > cache the the jaxws client object as an HTTP session attribute. It
> > doesn't work for some reason.
>
> Can you define "doesn't work"?
>
>
> > What does work is attaching the jaxws client object to the
> > application context, however this isn't a feasible solution.
>
> So, placing the client into the application via
> ServletContex.setAttribute("jaxclient", client) works?
>
>
> > I vaguely recall running into a similar problem with performing the
> > same task in jboss which i think had the requirement for adding a
> > @Serializable annotation to anything added to the session object.
> > Does tomcat require the same?
>
> Tomcat itself has no specific requirement for session attributes to be
> Serializable, unless you want your sessions to be "distributable" (as
> in a cluster). If you want to improve performance, using clustering
> isn't a great strategy, though.
>
> Tomcat won't fail immediately when adding a non-serializable object to
> the session. Instead, it will fail/log-error at the end of the
> request-processing when the changes to the session are propagated to
> the other node(s) in the cluster. Thus, your local session *should*
> continue to work.
>
> I'm curious about what takes so long when creating the JAXWS client.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAls42lEACgkQHPApP6U8
> pFhiyw//bRNRj/r6jvIi4WEBHTFt154fmvumT2eL56o3dmfxP+byylgcbwWm7z+P
> FvFkR76Vs15P7oSHARsCsSs3xfq46Nn/MyUkZzjdzFSXn4O39AOuzVB2M0NNMsrG
> G6xgrBxGCHD3Zfmk4R2cysqpDkWXjNDS1UlBgyn8DfO2kbjZu6f1OxU6Z9xtYDc0
> Shjfe+qrFo0kqI3XiJbn0PWB1QtTcF7eKjsOZMub/UsR5F1zH3KgdD7FYOvVllbP
> BaBxTdov6Jvbjg0RLKa9+fEmWFGbGkBq1daFLm6+SovSg1KXBzzidDi8k8qAly/P
> XjnNjV44l9mj4Uw1I7gArwvOGk/rm6X7m5NjIfeKjnB0rHpHwuqrrSL6sOvX2cEW
> UA+TX1sq06e9jeUiAzeS27H+Imfk6pNJycp5sW2JPiR7QTlvJwwJKlYIIs9TEiDo
> veQ0hAVRWTc/BPsthXJVakNW0cpySg8Jost/n0jBnl+ryjPnorBdCx6PVLbJ2RnY
> 1le5p4QCZRLRekDvO2PsGP0TRADWttPilumteTPgDR33KqookS9n02S9Ct6Lobdx
> 6YXFqtrlAMFzgdvyTtGgRU2J0a95JZWsLme+hLFqsiIAyS+wP8JfewhZr2paGFtI
> aTKdqTgyAXa6JmQqHOlZL6i+D8B6RawRl1xlcRc1FF1uEdPDmvc=
> =Y2qD
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
--
"Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better."
- Samuel Beckett
Re: Requirements for servlet session attributes?
Posted by Alex O'Ree <sp...@gmail.com>.
The jaws client maybe takes 100ms to fire up. So it's not terrible slow
but the overall website is noticeably faster when caching it. All of the
resources (wsdls, xsds) are local but there's a quite a few of them.
Caching this object does not work as a session attribute.
HttpServletRequest#setAttribute("mykey", clientObjectHere);
followed by
HttpServletRequest#getAttribute("mykey") == null on subsequent http
requests.
ServletContext#setAttribute and getAttribute does work however it is not
viable in my situation
On Jul 1, 2018 9:43 AM, "Christopher Schultz" <ch...@christopherschultz.net>
wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Alex,
On 7/1/18 7:48 AM, Alex O'Ree wrote:
> I was working on attempting to increase performance on a web app
> which calls a jaxws service on behalf of the user. The process for
> creating the jaxws client is somewhat slow so I was to try and
> cache the the jaxws client object as an HTTP session attribute. It
> doesn't work for some reason.
Can you define "doesn't work"?
> What does work is attaching the jaxws client object to the
> application context, however this isn't a feasible solution.
So, placing the client into the application via
ServletContex.setAttribute("jaxclient", client) works?
> I vaguely recall running into a similar problem with performing the
> same task in jboss which i think had the requirement for adding a
> @Serializable annotation to anything added to the session object.
> Does tomcat require the same?
Tomcat itself has no specific requirement for session attributes to be
Serializable, unless you want your sessions to be "distributable" (as
in a cluster). If you want to improve performance, using clustering
isn't a great strategy, though.
Tomcat won't fail immediately when adding a non-serializable object to
the session. Instead, it will fail/log-error at the end of the
request-processing when the changes to the session are propagated to
the other node(s) in the cluster. Thus, your local session *should*
continue to work.
I'm curious about what takes so long when creating the JAXWS client.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAls42lEACgkQHPApP6U8
pFhiyw//bRNRj/r6jvIi4WEBHTFt154fmvumT2eL56o3dmfxP+byylgcbwWm7z+P
FvFkR76Vs15P7oSHARsCsSs3xfq46Nn/MyUkZzjdzFSXn4O39AOuzVB2M0NNMsrG
G6xgrBxGCHD3Zfmk4R2cysqpDkWXjNDS1UlBgyn8DfO2kbjZu6f1OxU6Z9xtYDc0
Shjfe+qrFo0kqI3XiJbn0PWB1QtTcF7eKjsOZMub/UsR5F1zH3KgdD7FYOvVllbP
BaBxTdov6Jvbjg0RLKa9+fEmWFGbGkBq1daFLm6+SovSg1KXBzzidDi8k8qAly/P
XjnNjV44l9mj4Uw1I7gArwvOGk/rm6X7m5NjIfeKjnB0rHpHwuqrrSL6sOvX2cEW
UA+TX1sq06e9jeUiAzeS27H+Imfk6pNJycp5sW2JPiR7QTlvJwwJKlYIIs9TEiDo
veQ0hAVRWTc/BPsthXJVakNW0cpySg8Jost/n0jBnl+ryjPnorBdCx6PVLbJ2RnY
1le5p4QCZRLRekDvO2PsGP0TRADWttPilumteTPgDR33KqookS9n02S9Ct6Lobdx
6YXFqtrlAMFzgdvyTtGgRU2J0a95JZWsLme+hLFqsiIAyS+wP8JfewhZr2paGFtI
aTKdqTgyAXa6JmQqHOlZL6i+D8B6RawRl1xlcRc1FF1uEdPDmvc=
=Y2qD
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Requirements for servlet session attributes?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Alex,
On 7/1/18 7:48 AM, Alex O'Ree wrote:
> I was working on attempting to increase performance on a web app
> which calls a jaxws service on behalf of the user. The process for
> creating the jaxws client is somewhat slow so I was to try and
> cache the the jaxws client object as an HTTP session attribute. It
> doesn't work for some reason.
Can you define "doesn't work"?
> What does work is attaching the jaxws client object to the
> application context, however this isn't a feasible solution.
So, placing the client into the application via
ServletContex.setAttribute("jaxclient", client) works?
> I vaguely recall running into a similar problem with performing the
> same task in jboss which i think had the requirement for adding a
> @Serializable annotation to anything added to the session object.
> Does tomcat require the same?
Tomcat itself has no specific requirement for session attributes to be
Serializable, unless you want your sessions to be "distributable" (as
in a cluster). If you want to improve performance, using clustering
isn't a great strategy, though.
Tomcat won't fail immediately when adding a non-serializable object to
the session. Instead, it will fail/log-error at the end of the
request-processing when the changes to the session are propagated to
the other node(s) in the cluster. Thus, your local session *should*
continue to work.
I'm curious about what takes so long when creating the JAXWS client.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAls42lEACgkQHPApP6U8
pFhiyw//bRNRj/r6jvIi4WEBHTFt154fmvumT2eL56o3dmfxP+byylgcbwWm7z+P
FvFkR76Vs15P7oSHARsCsSs3xfq46Nn/MyUkZzjdzFSXn4O39AOuzVB2M0NNMsrG
G6xgrBxGCHD3Zfmk4R2cysqpDkWXjNDS1UlBgyn8DfO2kbjZu6f1OxU6Z9xtYDc0
Shjfe+qrFo0kqI3XiJbn0PWB1QtTcF7eKjsOZMub/UsR5F1zH3KgdD7FYOvVllbP
BaBxTdov6Jvbjg0RLKa9+fEmWFGbGkBq1daFLm6+SovSg1KXBzzidDi8k8qAly/P
XjnNjV44l9mj4Uw1I7gArwvOGk/rm6X7m5NjIfeKjnB0rHpHwuqrrSL6sOvX2cEW
UA+TX1sq06e9jeUiAzeS27H+Imfk6pNJycp5sW2JPiR7QTlvJwwJKlYIIs9TEiDo
veQ0hAVRWTc/BPsthXJVakNW0cpySg8Jost/n0jBnl+ryjPnorBdCx6PVLbJ2RnY
1le5p4QCZRLRekDvO2PsGP0TRADWttPilumteTPgDR33KqookS9n02S9Ct6Lobdx
6YXFqtrlAMFzgdvyTtGgRU2J0a95JZWsLme+hLFqsiIAyS+wP8JfewhZr2paGFtI
aTKdqTgyAXa6JmQqHOlZL6i+D8B6RawRl1xlcRc1FF1uEdPDmvc=
=Y2qD
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org