On 1/11/06, Wendy wrote: >I may have edited it out, but one question I had was, what kind >of volume are we talking about here? Five transactions an hour? A minute? A second? More?
300 authorizations an hour, max; 2 thousand a day, max. This is growing steadily though. >You do *not* want to do the equivalent of: >PCPERFORM "java com.exampleMyClass param1 param2" >either directly, or indirectly by calling a script that does the same thing. It's going to >create a JVM (Java Virtual Machine) every time. That won't scale at all. That's wild, a separate JVM for each thread? I thought it was been slow to load but... So, I just kicked off a runLPClientTest.sh and set the thread count to 18. Then from another session I did 'ps -eaf | grep java' Only 1 process was spawned. Doesn't this mean just 1 jvm? >I'm finding it hard to believe that a Java API is the only way to talk to the LiveProcessor >software _and_ that all you can do with the Java API is make a call to process a single >transaction. But assuming that's all true, I'd approach this one of two ways: They have a C API as well. Do you think that would be faster/thinner? I see now, UV is much more prepared to do a C call, than a Java call. In-house talent pool was leaning us toward the Java API. >I'd still lean towards a sockets-based solution. UV would use CallHTTP to talk to an >instance of Jetty or Tomcat running a little Servlet that picks up HTTP request parameters, >makes the call to the LP server, gets that response, and then sends a response back to UV. We are doing something like this now to perform an extended search on a webservice for parts lookup, but it seems rather slow. Maybe it's just the 492kz+ parts it's searching through. >I don't like this as much: Have UV write a record to a table with the transaction >information. From Java, with UOJ, constantly read records from that table, process the >transactions, and write back to it. Make sure you lock the records properly. This would be a single threaded solution? (1 phantom or cron to control) and require polling? (which means the next batch can't start until the last one ends) The reason I thought we should make 1 auth = 1 call is to immediately service each Auth request, as soon as CSR hits <Rtn> key to File order (or whatever trigger we invent in order taking process, though CSR will not be waiting, necessarily, for response. We close the sale whether/not Auth has been received, leave it to Credit to mop up later). >I don't see why you can't talk directly to the LiveProcessor software with CallHTTP or a >plain Socket, though. Their Java client has to be connecting somehow... The Java client is connecting with TCP to the LP software. Thanks for help, it's keeping the cranial juices flowing. -Baker ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
