Replies: 3 comments 2 replies
-
Take a thread dump from the jvm. I prefer
No. The code doesn't log its progress on a file, by file basis. File readers (and I think all other polling connectors) run a single thread for the poll, then that single thread can generate multiple messages which can then be processed by the source connector threads. |
Beta Was this translation helpful? Give feedback.
-
Trying to see what the speed is for a file reader to read in files from an smb drive, destination is a file writer to a mapped network drive. So, it sounds like increasing the source threads only affects it processing through the channel. The channel is set to move the message as an attachment. No processing happening with the message. Just moving them from one place to another. So doesn't sound like increasing threads will do anything. |
Beta Was this translation helpful? Give feedback.
-
Thks. The source is reading from an Epic hosted drive we are connecting using smb. The destination is writing to a mapped server (located on the same subnet as the mirth appliance occupies). Destination queueing is enabled but it never queues. Apparently, there is an issue with mapping the Epic drive in the appliance as a network drive. It works for a while and then loses the connection. You have to continually remap the drive. |
Beta Was this translation helpful? Give feedback.
-
If I set the Max Threads on a source file reader, is there any way to actually see how many threads are running for that channel?
Also, for a file reader, is there any way to tell what file it is currently reading? I added a filename and start time in the source transformer, but that doesn't really give you the time it started reading the file, I was going to add some javascript to the attachment handler to record the start but that is already set to Entire Message to create an attachment.
Beta Was this translation helpful? Give feedback.
All reactions