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]
