Funny you should suggest that. We're currently considering this as an option.
The DF1 protocol is a stone-age protocol used by Allen-Bradley Programmable Logic Controllers and as such is very inflexible. While we work on this, we're gonna work with our load balancer and try to get our sessions to be extra-sticky so that the likelyhood of two different requests from a PLC going to different WAS servers is greatly reduced. It certainly is a pickle of a situation! Simon >-----Original Message----- >From: Joseph Fifield [mailto:[EMAIL PROTECTED] >Sent: Thursday, October 16, 2003 6:06 PM >To: Struts Users Mailing List >Subject: Re: [Semi OT] When does a servlet get a session? > > >I suppose you could fake the http requests yourself, couldn't >you? When the >DF1 request comes in, translate it to an http get or post >request and send >it off to your existing struts system. Translate the http response into >whatever is needed for the DF1 response. > >Also, does this DF1 protocol have any notion of a session? In >other words, >is there some unique identifier sent with each request to tie >it to other >requests, or are all requests basically global? Either way, >you would need >to send an appropriate jsessionid value back with your fake >http requests in >order to maintain the same http session. > >Joe > >----- Original Message ----- >From: "Chappell, Simon P" <[EMAIL PROTECTED]> >To: "Struts Users Mailing List" <[EMAIL PROTECTED]> >Sent: Thursday, October 16, 2003 5:31 PM >Subject: RE: [Semi OT] When does a servlet get a session? > > >Craig, > >>-----Original Message----- >>From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] >>Sent: Thursday, October 16, 2003 4:19 PM >>To: Struts Users Mailing List >>Subject: Re: [Semi OT] When does a servlet get a session? >> >> >>Chappell, Simon P wrote: >> >>>You're right that we'll never have an HTTP request, so I can >>see why you're confused as to why we'd want a session. The >>reason is for performance. We want to avoid the overhead of >>writing and reading a database. This is very short term >>information, but now that we're needing to run in a >>load-balanced cluster, we need to be able to handle the >>situation where requests could, in the worst case scenario, >>come into each server alternatively. IBM's WebSphere App. >>Server when running in a cluster will propogate the session to >>any server that needs it. Thus if we use a session, it'll >>propogate back and forth between the boxes. >>> >>> >>The problem you're going to have is that there is no such thing as an >>HttpSession without an HTTP request. > >We found that out! :-( > >>Even if you could do what you >>propose, it would only make the stored information available >>to a single >>user -- that doesn't seem like it will do what you want. > >Actually, it is exactly what we want. This servlet only exists >to start our >socket listener. This is a "certifiably awful hack", but they >wouldn't let >us run a separate server application, so when all you have is a servlet >engine, everything looks like a hammer (or something like that). > >>A possible strategy to avoid READING the database on every >>request is to >>have a webapp startup method load the data into a servlet context >>attribute. This will happen on each node the app is deployed to, but >>will happen only once (before the first request is processed). > >Actually, we have something like that now, where we store >information in a >static variable in the servlet. That works fine. The issue is >that for WAS >to replicate it between server instances, it needs to be in the servlet >session that we don't have. > >The other challenge is that we don't have any control over the >DF1 protocol >or the serial to IP device that calls our listener. We asked >our engineers >if they could try faking some HTTP and then we could send the traffic >through our existing Struts based system, but it would seem that is not >possible with the current hardware situation that they work with. > >Simon > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
