Class loaders maintain isolation of contexts, so calling a method on a different servlet can be tricky, but that is possible. Although, take into account that the container maintains pools of servlets, so something like a static service method, assuming you can crack the class loader nut, might work.
In the design of your service, you would need to define (possibly static) methods that encapsulate the functionality you'd like to execute (reuse). Without doing something that would be considered a violation of security principles in computing (SPECTR notwithstanding), I think you'll have a very difficult time with this requirement. The JVM may be doing some optimizations for localhost requests that speed things up, but I can't confirm that at present (and my instincts say it isn't). This brings up the point about performance vs scalability. When you are proxying network requests like this, scalability can keep your request/processing times normative (assuming you don't have a database problem). Assuming your baseline request/response times are acceptable, using scalability techniques is generally preferred to unrelenting performance optimizations not including memory leaks. That said, I get your sentiment, and applaud your desire to make things go fast. Awesome! On 5/6/19, Paul Carter-Brown <paul.carter-br...@jini.guru> wrote: > I think we are completely missing each other. Forget sockets - that was > just an example. I have code running in a Tomcat App server which is not > managed by Tomcat and is not initiated by anything within Tomcat. That code > now wants to call a servlet hosted in that very same JVM. Any way to do > that without going out and back in on TCP? > > > On Mon, May 6, 2019 at 5:14 PM John Dale <jcdw...@gmail.com> wrote: > >> Sockets are an implementation of TCP/UDP inherently. >> >> Perhaps a mountaintop signal fire? >> >> ;) >> >> John >> >> >> On 5/6/19, Paul Carter-Brown <paul.carter-br...@jini.guru> wrote: >> > lol on the Semaphore Telegraph, >> > >> > I can't use a request dispatcher as the request is being initiated from >> > code that has no context. I already have it working with HTTP using >> > asynchttp library, but I want to avoid the overhead. E.g. lets say I >> wrote >> > my own server socket listener on port 10000 running in the Tomcat JVM >> > and >> > got some request in some propriatary protocol called X. Now I want to >> call >> > a Tomcat servlet in the current JVM with some info I got over X without >> > going out on TCP and back in.... >> > >> > On Mon, May 6, 2019 at 4:40 PM John Dale <jcdw...@gmail.com> wrote: >> > >> >> If you're wanting to forward control to another servlet deployed in >> >> the same context: >> >> https://www.javatpoint.com/requestdispatcher-in-servlet >> >> >> >> If you are okay going through TCP to facilitate some future or current >> >> distribution of services, Use HTTPURLConnection (not sure what you're >> >> wanting to do with the result of the request, if anything): >> >> >> >> >> https://stackoverflow.com/questions/2793150/how-to-use-java-net-urlconnection-to-fire-and-handle-http-requests >> >> >> >> If you need more sophisticated HTTP interactions, Apache maintains a >> >> very useful library for that: http://hc.apache.org/ >> >> >> >> If these don't work-out for you, rather than using .NET, PHP, Python, >> >> or some other Java facsimile at best, I recommend using the semaphore >> >> telegraph: >> >> https://en.wikipedia.org/wiki/Semaphore_telegraph >> >> >> >> Sincerely, >> >> >> >> John >> >> DB2DOM >> >> >> >> On 5/6/19, Paul Carter-Brown <paul.carter-br...@jini.guru> wrote: >> >> > Hi John, >> >> > >> >> > Thanks for your feedback. >> >> > >> >> > The request I'm initiating should not or need not carry any context >> >> > from >> >> > the originating code. There is also no session to worry about as its >> >> > just >> >> > for rest calls. So basically I have the headers, path and body and >> need >> >> to >> >> > generate a http servlet request and get an http servlet response (or >> >> > similar) back. I have this working by calling into localhost but >> >> > ideally >> >> > want to skip the trombone out and back in. >> >> > >> >> > Have you got any basic code examples? >> >> > >> >> > Paul >> >> > >> >> > On Tue, Apr 30, 2019 at 5:27 PM John Dale <jcdw...@gmail.com> wrote: >> >> > >> >> >> Another thought .. you can do some request dispatching, but without >> >> >> knowing more about the tools you're using, I can't say for sure if >> >> >> this is the direction you'll want to go. >> >> >> >> >> >> On 4/29/19, Paul Carter-Brown <paul.carter-br...@jini.guru> wrote: >> >> >> > Hi >> >> >> > >> >> >> > I'm trying to design a Kafka consumer and producer that will run >> >> inside >> >> >> the >> >> >> > tomcat jvm and pick up messages off a Kafka topic and translate >> them >> >> >> into a >> >> >> > servlet request and pass it through tomcat and then when the >> >> >> > response >> >> >> > is >> >> >> > complete then translate it into a Kafka message and put it onto >> >> another >> >> >> > topic as a reply. This way I can reuse our existing jax-rs rest >> >> >> > services >> >> >> > and expose them as an async api over Kafka. The idea is to make >> >> >> > the >> >> >> > Kafka >> >> >> > messages similar to http in that they would consist of headers >> >> >> > and >> a >> >> >> body. >> >> >> > The body would be json. >> >> >> > >> >> >> > Now I know this could be done by calling localhost with an http >> call >> >> to >> >> >> > trombone the requests back into tomcat but I'd like to avoid the >> >> >> associated >> >> >> > latency and overhead. Is it possible to call tomcat directly >> >> >> > in-process. >> >> >> > This does not need to be portable to other containers so can be >> >> >> > proprietary. >> >> >> > >> >> >> > I'm using tomcat 8. In fact its tomee 8 but guessed this is more >> >> >> > a >> >> >> > tomcat >> >> >> > question than tomee but have sent to both groups just in case. >> >> >> > >> >> >> > Thanks for any insights. >> >> >> > >> >> >> > Paul >> >> >> > >> >> >> >> >> > >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >> >> >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
