Win a copy of Grokking Bitcoin this week in the Cloud/Virtualization forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Paul Clapham
  • Devaka Cooray
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Frits Walraven
Bartenders:
  • Carey Brown
  • salvin francis
  • Claude Moore

What message to send to JMS while my request is running?  RSS feed

 
Ranch Hand
Posts: 106
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So, I've seen simple Spring JMS example (like this:https://codenotfound.com/spring-jms-activemq-example.html,) where a producer sends out a message to the Apache MQ and consumer receives the message.

I am trying to figure out how to handle the long running stored procedure using JMS in my scenario explained below.

Suppose, I have the following stored procedure when I am going to call as soon as user do the following:

1) Make an Ajax POST call
2) Request comes to a REST end point with parameters.
3)An interface (data access object) contains unimplemented methods.
4)A data access object implementation class is where communication with the oracle database happens.

My stored procedure looks like the following:




As soon as the parameters are sent into the above procedure, there is a separate table (STATUS_CHECK) available that logs the status of the request. For example, I can query this table and see various statuses like
RUNNING, COMPLETE, RUNNING NOW etc.  

In a scenario, where I wouldn't have used JMS, I would have call the stored procedure in DAO Implementation class and the procedure would have inserted the parameters into the tables.
And as soon as the status in STATUS_CHECK table shows COMPLETE, I could have selected data from different tables so that I could send it to the UI for download.

Scenario where I am trying to bring in JMS here :

Since the stored procedure could take hours and maybe a day, I would like to forward something to the JMS Queue as soon as stored procedure receives the parameters and the table STATUS_CHECK starts showing
"RUNNING" status. As soon as the status from the STATUS_CHECK table shows "COMPLETE",I know that whatever data I need to send to the UI is available in some other tables and  I can grab and send it to the UI.


Considering above scenario, what is this "something" I should look for to send to the JMS queue when the STATUS_CHECK table shows RUNNING so that my application could handle asynchronous requests?


 
 
Sheriff
Posts: 24368
55
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've read your post a couple of times and I'm still confused. I don't understand the purpose of your JMS queue, and I don't see where you describe the responsibilities of the producer and the consumer. You also have this stored procedure but you don't describe what's running it.
 
Bartender
Posts: 1120
38
IBM DB2 Java Netbeans IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jack, as Paul wrote, your post isn't much clear about what piece of code will do what.. Nevertheless, let's try to summarize:you need to call a long lasting stored procedure, when an user executes a given operation on your application UI, and you want to be notified when the SP ends, presumably without looking on the status table, and you thought to use JMS to get such notification asinchronously. Right?
 
Paul Clapham
Sheriff
Posts: 24368
55
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jack Tauson wrote:And as soon as the status in STATUS_CHECK table shows COMPLETE, I could have selected data from different tables so that I could send it to the UI for download.



It seems to me that this is the key requirement which you're trying to deal with, right?

I assume that the stored procedure is not set up to notify anything, it just sets that status code to COMPLETE and then terminates. Of course the termination could be considered to notify the task which is running the stored procedure, but it looks to me like that task is just running on its own and no other task is watching it.

So if you want to find out whether the stored procedure has finished, you have to look at the status code to see if it says COMPLETE. Nothing is going to tell you when it changes from RUNNING to COMPLETE, so it seems to me that you would just have to look periodically to see if the status is COMPLETE yet.

Based on my understanding of the problem, this is where my mind has led me.

However if you want to have JMS as part of the solution, then perhaps the task which runs the stored procedure could send a JMS message to some other task to notify it that the stored procedure has finished. Since the message itself means that the stored procedure has finished, it wouldn't actually have to contain any other information at all. In this case the STATUS_CHECK table become irrelevant.

And you talked about sending the data to "the UI". I'm assuming that this UI will be running unattended on some machine somewhere, since having a person watching it for several hours is impractical. Am I right? If that's the case then the UI could be the JMS message consumer, and it would update itself when it received a message.

On the other hand the unattended UI application could also look at the status code every (e.g.) 10 seconds and when it sees the status code is COMPLETE, it could then update itself. This seems easier to me than inserting JMS into the design.

Are any of these ideas on track?
 
Jack Tauson
Ranch Hand
Posts: 106
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Paul Clapham wrote:

Jack Tauson wrote:And as soon as the status in STATUS_CHECK table shows COMPLETE, I could have selected data from different tables so that I could send it to the UI for download.



It seems to me that this is the key requirement which you're trying to deal with, right?

I assume that the stored procedure is not set up to notify anything, it just sets that status code to COMPLETE and then terminates. Of course the termination could be considered to notify the task which is running the stored procedure, but it looks to me like that task is just running on its own and no other task is watching it.

So if you want to find out whether the stored procedure has finished, you have to look at the status code to see if it says COMPLETE. Nothing is going to tell you when it changes from RUNNING to COMPLETE, so it seems to me that you would just have to look periodically to see if the status is COMPLETE yet.

Based on my understanding of the problem, this is where my mind has led me.

However if you want to have JMS as part of the solution, then perhaps the task which runs the stored procedure could send a JMS message to some other task to notify it that the stored procedure has finished. Since the message itself means that the stored procedure has finished, it wouldn't actually have to contain any other information at all. In this case the STATUS_CHECK table become irrelevant.

And you talked about sending the data to "the UI". I'm assuming that this UI will be running unattended on some machine somewhere, since having a person watching it for several hours is impractical. Am I right? If that's the case then the UI could be the JMS message consumer, and it would update itself when it received a message.

On the other hand the unattended UI application could also look at the status code every (e.g.) 10 seconds and when it sees the status code is COMPLETE, it could then update itself. This seems easier to me than inserting JMS into the design.

Are any of these ideas on track?





It seems to me that this is the key requirement which you're trying to deal with, right?

Answer: You can say that.Since the procedure is going to take lot of time, as you mentioned, I think I would have to keep checking the status from time to time. So as soon as the
request reaches the stored procedure below, another procedure responsible to populate data in 4 different tables is launched asynchronously by the below one.




This is what I was thinking keeping JMS in mind. Please let me know if this sounds feasible solution or not:


As soon as I get the parameters which are needed to run the stored procedure in the "data access object implementation class", after calling the stored procedure, I would know what's the status of the request
would be by checking the STATUS_CHECK table. So maybe I could keep on pushing "RUNNING" message to the JMS queue until I get the message "COMPLETE". At the same time, my consumer will keep on checking
what's the latest message is on the queue, so basically, as long as the messaage on the queue is "RUNNING", the conde inside consumer won't do any thing. As soon as consumer sees that the message is "COMPLETE",
I could go ahead and do other stuff like grabbing data from other tables. How does this sapproach sounds? Please let me know if it's erroneous.


Reason why I have been thinking of using JMS here :

User is interacting with multiple download buttons, let's say they click on the "Download" option here  http://jsfiddle.net/zs3wnbm5/1/ and each of the option calls the above procedure which is going to
take time (hours or maybe a day). If I don't use JMS here, then after clicking the first "Download" option, I believe user won't be able to do other tasks like if they want to click other "Download" option
or click view button etc. Basically, it's not going to be asynchronous behavior at the back end I believe and hence I am planning to introduce JMS here.


And you talked about sending the data to "the UI". I'm assuming that this UI will be running unattended on some machine somewhere, since having a person watching it for several hours is impractical. Am I right? If that's the case then the UI could be the JMS message consumer, and it would update itself when it received a message.

I think I was missing this part last time. I would actually be grabbing the data and generating the CSV files from that data and maybe put it somewhere on the server or would directly send the files(there are going to be
multiple files) in the Zip format to the user for download. (Not sure if sending it directly is even possible or not). I will think about it later once above problem is sorted out.

On the other hand the unattended UI application could also look at the status code every (e.g.) 10 seconds and when it sees the status code is COMPLETE, it could then update itself. This seems easier to me than inserting JMS into the design. [i]

I think in this scenario, the UI would be tied to this particular request only,right? and until this request finishes, the user won't be able to do other things as I explained above in the "Reason why I have been thinking of using JMS" section.


Please let me know if something is still confusing from my explanation point of view. I appreciate spending time in reading my post multiple times and answering my questions.
 
Jack Tauson
Ranch Hand
Posts: 106
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Claude Moore wrote:Hi Jack, as Paul wrote, your post isn't much clear about what piece of code will do what.. Nevertheless, let's try to summarize:you need to call a long lasting stored procedure, when an user executes a given operation on your application UI, and you want to be notified when the SP ends, presumably without looking on the status table, and you thought to use JMS to get such notification asinchronously. Right?



Hey Claude, Hopefully my above explanation to Paul's questions would answer your questions. Please let me know if I need to elaborate more on anything. Appreciate spending your time here and trying to help me.
 
Paul Clapham
Sheriff
Posts: 24368
55
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jack Tauson wrote:So maybe I could keep on pushing "RUNNING" message to the JMS queue until I get the message "COMPLETE". At the same time, my consumer will keep on checking
what's the latest message is on the queue, so basically, as long as the messaage on the queue is "RUNNING", the conde inside consumer won't do any thing. As soon as consumer sees that the message is "COMPLETE",
I could go ahead and do other stuff like grabbing data from other tables. How does this sapproach sounds? Please let me know if it's erroneous.



No, that would be pointless. Sending a JMS message which is guaranteed to be ignored? No. Just don't send that message. So then you're only sending the COMPLETE message, which is what I already suggested.

I think in this scenario, the UI would be tied to this particular request only,right? and until this request finishes, the user won't be able to do other things



I don't know why you would say that. Yes, the UI would be tied to that request. But you have to remember that I'm at a severe disadvantage in that I know absolutely nothing about this UI which you keep mentioning. And anyway what's to stop it from waiting for COMPLETE in one thread while doing useful user-related things in other threads?
 
Jack Tauson
Ranch Hand
Posts: 106
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

No, that would be pointless. Sending a JMS message which is guaranteed to be ignored? No. Just don't send that message. So then you're only sending the COMPLETE message, which is what I already suggested.



Ok. So I think you are suggesting here to just send the COMPLETE message to JMS Queue. Consumer would keep on looking for this message and as soon as it finds this message, I could start doing other stuff like grabbing data from other tables etc, right?


Sorry for not being clear on the UI part. UI is just made up of HTML/Javastipt/CSS and is deployed in the springboot app. Let me not confuse you any more and try to explain briefly about what a REST point could expect. I think it would be enough to know that front end could send a series of requests to REST end point.By series of request I mean :

1) User sends an Ajax request which triggers this stored procedure, and this SP is going to take long time.
2) While the request in Step #1 is still running, user could send another Ajax request ( I don't know if this is possible or not because I am using Ajax; I might have to use something else to handle (send and receive) asynchronous requests)
3) Similarly, if the above two requests are still RUNNING, user could send 3rd request and so on and so forth.


Coming back to your questions/responses :

I don't know why you would say that. Yes, the UI would be tied to that request.



I am worried that if a user sends a request to the REST controller and since the whole process if going to take time, user should not get stuck because of this and should be able to perform other tasks (the series of tasks that I mentioned in my explanation above). I guess I would have to handle this part on the front end side somehow.

And anyway what's to stop it from waiting for COMPLETE in one thread while doing useful user-related things in other threads?



Sorry, I didn't understand this part completely. Are you referring that I could use multi threading instead of JMS here?

Thanks again for your valuable inputs. Looking forward to your responses.
 
Paul Clapham
Sheriff
Posts: 24368
55
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jack Tauson wrote:1) User sends an Ajax request which triggers this stored procedure, and this SP is going to take long time.
2) While the request in Step #1 is still running, user could send another Ajax request ( I don't know if this is possible or not because I am using Ajax; I might have to use something else to handle (send and receive) asynchronous requests)
3) Similarly, if the above two requests are still RUNNING, user could send 3rd request and so on and so forth.



Not quite... the first Ajax request would trigger the stored procedure and then return immediately. That would leave some other process running the stored procedure; perhaps that Ajax request could send a JMS request to a consumer whose job is to run the stored procedure.

Subsequent requests would look to see at the status of the stored procedure, and return something like "The stored procedure is already running". Or if the status is COMPLETE, then they would return the result of the stored procedure.

To put it another way, the Ajax request would either trigger the stored procedure and let the user know that happened, or tell the user that the stored procedure is running, or return the result of the stored procedure. Based on the status code.

Sorry, I didn't understand this part completely. Are you referring that I could use multi threading instead of JMS here?



You could do that, but based on your description of the UI you wouldn't use multi-threading and you wouldn't use JMS either. Your UI would just have the ability to submit, query, or download but none of those things would block other UI features because they aren't long-running requests. (Long-running requests are a bad idea because they are likely to time out anyway.)

And it looks like having the stored-procedure processing task use JMS to send completion notifications may be unnecessary -- it doesn't look like there's anything in the UI which has to react immediately to that.

However it would be possible to have a web page in your Spring Boot app which just sat there and, once a minute or something like that, it would send a request asking whether the stored procedure was complete. No user interaction is necessary when you do that, it just sends the request repeatedly. It would be nice if the response could say "It's 72% complete" but it doesn't look like that's a possibility.
 
Jack Tauson
Ranch Hand
Posts: 106
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

That would leave some other process running the stored procedure; perhaps that Ajax request could send a JMS request to a consumer whose job is to run the stored procedure.



As soon as the stored procedure is called, it records the details of the request and returns a request key and message immediately. The procedure that gathers the data is launched asynchronously by this procedure call. So the person who has designed the stored procedure is doing this. I don't think I have control over here where I could have my Ajax request send JMS request to a consumer whose job is to run the stored procedure.


Your UI would just have the ability to submit, query, or download but none of those things would block other UI features because they aren't long-running requests. (Long-running requests are a bad idea because they are likely to time out anyway.)



Actually, since the stored procedure is going to run for a while in the back, if I am using Ajax, it could be a long request unless I handle it in some fashion. And I would have to do that because of time out issue.I think I am trying to discuss both UI and backend here simultaneously and that might be creating confusion. Let's maybe keep the UI discussion aside for sometime. I'll discuss about back end only below so that it would be easy to sort out the back end part first.

Let's say I am using POSTMAN client to send the request to the REST end point. Based on your understanding of the problem/scenario we discussed thus far, where do you see JMS coming into in my process?

Appreciate your time again. Thanks !
 
Creativity is allowing yourself to make mistakes; art is knowing which ones to keep. Keep this tiny ad:
ScroogeXHTML - the small and fast RTF to HTML converter library
https://coderanch.com/t/707504/ScroogeXHTML-RTF-HTML-XHTML-converter
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!