search

juks / iso-8583-socket-queue

ISO 8583 gateway
MIT License
194 stars 111 forks source link

Socket Queue storage location #29

Closed VictorDusautois closed 6 years ago

VictorDusautois commented 6 years ago

Hi Juks,

Is it possible to configure the storage location for the queue to survive restarts? Currently When we send a request from same TID it actually gets queued, and suppose there was a system/network failure for a few seconds we will loose all the messages in the queue.

Can you please advise how is the queue mechanism implement with SocketQueue and if we can extend it to use some sort of persistent queueing technology with it.

juks commented 6 years ago

Hi Victor!

Just give me some time to move the storage methods into separate module, so you could override them according you storage preferences.

VictorDusautois commented 6 years ago

Hi Juks,

Thanks for the response. There is one issue which we have encountered during PoC and this was the reason we are looking to externalise the queue and monitor from their.

We had done like stress testing with 10K transactions and after a month we realized when we shut down the Socket Queue, it sent few transactions one month back dated to the ISO upstream host. Is it that the transactions which have failed to get response from upstream are queued on SocketQueue and are flushed to Upstream when we shutdown or kill the process?

Is there a way to currently view the items in the queue from other processes if it's stored in memory or file on SocketQueue?

juks commented 6 years ago

SocketQueue performs graceful quit: it waits for the response of every active transaction (active means already send to the upstream). In case of timeout it starts auto-reversals for every purchase transaction. Only after every auto-reversal transaction gets response of reaches timeout, it quits.

I need more details on the case of one month dated transactions.

There are two log messages that reflect the queue status right now:

So if you spot that “pending” / “total” never goes to zero and there are same IDs in the queue for a long time — then something goes wrong.

Is there a way to currently view the items in the queue from other processes if it's stored in memory or file on SocketQueue?

It is possible to add this king of method. Will consider it.

VictorDusautois commented 6 years ago

Hi Juks,

Below is log, if you can advise something we can improve.

Actually the message is not sent to upstream and it timed out and dropped the client. But once we hit Ctrl+C to force stop, it sends the data to upstream at this stage. Is it expected behavior?

2018-04-17 12:17:56 - info: Important: starting...
2018-04-17 12:17:56 - info: Remote host configuration name: smartVista
2018-04-17 12:17:56 - info: Connecting to upstream server 192.168.0.1:6666
2018-04-17 12:17:56 - info: Relay raw ISO-8583 server is now running on port 2100
2018-04-17 12:17:56 - info: Relay HTTP server is now running on port 2110
2018-04-17 12:17:56 - info: Connected to upstream 192.168.0.1:6666!
2018-04-17 12:17:56 - info: Processing queue [pending 0 / total 0]
2018-04-17 12:17:56 - info: The queue is empty
2018-04-17 12:18:02 - info: New HTTP socket
2018-04-17 12:18:02 - info: Client http:::ffff:192.168.0.1:64857 connected
2018-04-17 12:18:02 - info: Client http:::ffff:192.168.0.1:64857 sent data
2018-04-17 12:18:02 - verbose:

http:::ffff:192.168.0.1:64857

 [Echo Response]

 Message Type Indicator [0].......................1800
 Bitmap [1].......................................82200000008000000400000000000000
 Transmission Date and Time [7]...................20180903204608
 System Trace Audit Number [11]...................204608
 Card Acceptor Terminal Identification [41].......TRM00002
 Network Management Information Code [70].........301

================================================================================================

2018-04-17 12:18:02 - info: Writing to queue http:::ffff:192.168.0.1:64857 [0]
2018-04-17 12:18:02 - info: New queue item 1
2018-04-17 12:18:02 - info: Processing queue [pending 1 / total 1]
2018-04-17 12:18:02 - verbose: Queue keys dump: 1
2018-04-17 12:18:02 - info: Upstreaming data for http:::ffff:192.168.0.1:64857
2018-04-17 12:18:02 - verbose: [00671800...]
2018-04-17 12:18:37 - info: Queue notice: http:::ffff:192.168.0.1:64857 reached queue timeout
2018-04-17 12:18:37 - info: Dropping the client http:::ffff:192.168.0.1:64857
2018-04-17 12:18:37 - info: Client http:::ffff:192.168.0.1:64857 gateway timeout
2018-04-17 12:18:37 - info: Client http:::ffff:192.168.0.1:64857 event
2018-04-17 12:18:37 - verbose: Releasing terminal TRM00002 with the key 1
2018-04-17 12:18:37 - info: Warning: client http:::ffff:192.168.0.1:64857 [queue id 1] terminated activity
2018-04-17 12:18:37 - info: Processing queue [pending 0 / total 0]
2018-04-17 12:18:37 - info: The queue is empty

juks commented 6 years ago

What does this part of log says:

VictorDusautois commented 6 years ago

Pardon, I didn't get your question. That's all I have in log after I restart a fresh SQ.

VictorDusautois commented 6 years ago

Can I share with you a very small Socket server written in Java, to reproduce this behaviour? Then you can configure SocketQueue to this upstream java server on your machine and test.

juks commented 6 years ago

If it can't be reproduced with SQ only, yes you can share.

Could you please provide a text description of the steps one has to perform to reproduce the case?

juks commented 6 years ago

I think this case worth opening a separate github issue.

juks commented 6 years ago

The default queue storage logic is now in separate file: /lib/iso8583-queue/lib/storage/queueMemory.js.

There is no straightforward way just to implement the database storage since the queue also keeps the actual senders socket objects. After a system failure all the connections will be lost.

To make a complete failsafe solution, there have to be multiple instances of the application with the tcp stack replication and queue replication or tcp replication and common queue storage.