I am experiencing an issue where AMTU fails to "clean up" files that have been sent to AMZN.
this is impacting AMZN and us. However, the friendly folks at AMZN rarely want to acknowledge let alone support AMTU.
Running on Windows 2000 server, has been in production for 18 months and has been unchanged for 6 months.
Using an advanced variant of text files. We send a product, image, and inventory file that has specific sets of fields. Files are limited to about 3 mb in size in order to keep the processing time down.
About a month ago AMTU started failing to clean up after sending files. We finally found this in troubleshooting another issue. Basically what happens is AMTU sees the outgoing files in /outgoing.
They are moved to /temp
It sends one. The log shows the file being acknowledge with a confirmation # from AMZN.
It doesn't move the file to sent, instead it goes into a tailspin and resends the file every 5 minutes til hell freezes over.
I have tried removing and resetting the config. I have not tried reinstalling or upgrading. While I'm sure something has changed the basic functionality is there and lacking a change log or some other rational reason I'd rather not upgrade. i.e. if it isn't broke don't rip and replace. I also think we might learn from the current broken state.... at least to the point of figuring out why it did this.
I am having the *exact* same problem and Amazon support won't help me worth a damn. If this tool is so unsupported they shouldn't have recommended it to us. Yes, they said we should use AMTU over all other solutions. Now that it is broken, they say we're SOL. Please, if anyone knows what's going on, we need a fix! :)
I installed it on another computer and it "solved" the issue. :)
Is there anything in the debug or error log when trying to send messages? I've seen a couple of situations where I had to do a little cleanup to get things rolling again.
I am currently encountering the same issue. Unfortunately, the error, debug and audit logs do not indicate that any error has occurred. Does anyone have any further insight into this problem?
Would rebooting the machine help?
After a little investigation, it appears as though it is HSQLDB related. It looks like the hsqldb used by AMTU is configured to run pretty much in memory (given hsqldb.cache_scale=14), which means the database will grow until it runs out of memory, unless you specifically up the default heap size in the amt.conf file to:
# Maximum Java Heap Size (in MB)
This is a temporary solution, and it appears to be working.
This would also explain why installing on a new machine seemed to have worked. The new machine has a fresh database - galegaDb.script will be close to 0MB instead of ~21MB (which seems to be the breaking point in my situation).
I will post an update if this turns out not to be the case.
Update - the hsqldb used by AMTU is configured as an in memory database, which seems to slowly grow. Unfortunately, this means you must increase the heap size in order to allow the database to exist in memory.
An alternate solution is to shutdown AMTU, update the first 3 lines of the galegaDb.script from "CREATE TABLE" (table stored in memory) to "CREATE CACHED TABLE" (table stored on disk). The next time you start AMTU, the galegaDb.script will reduce it's size to a few kb, pushing most of this information to the galegaDb.data file and galegaDb.backup file.
The ultimate solution would be for the AMTU to kill old entries, thus reducing the overall size of the database. I'm not sure why it's not doing that now.
I had this exact same problem, we run 4 instances of AMTU and 2 of them just started doing this - moving the feed files from the outgoing folder, into the temp folder and then nothing more. This is on AMTU systems that have been running fine for about 8 months.
The AMTU logs showed a problem with the credentials - but these hadn't been changed at all, and were correct for logging into seller central.
After reading this post, I started poking around the database files mentioned by Matt. My galegaDb.script files were at 3.5mb for 2 AMTU's and around 9mb for a third - so it would appear size was not the problem. I did however add the CACHED statment as Matt suggested. It did alter the file sizes as he said it would, but made no difference - AMTU was still refusing to move any files out of the temp folder.
I opened the galegaDb.script file in Notepad, it contains load of create table statments, alias statments, and then thousands of INSERT INTO statments.
I noticed that the very last of the INSERT INTO statements was incomplete - it had been truncated half way through. There was then thousands of empty lines.
I removed the truncated INSERT INTO statement, removed all the whitespace, saved the file, and restarted AMTU - lo & behold - it started woring as it should again!
I moved the files out of the temp folder back into the outgoing folder and it sent them, and moved them to then sent folder. Processing reports then arrived shortly after and it would appear as everything was back to normal.
I did this to the other instance of AMTU that was also giving the same problem and it worked again.
I have no idea why this truncating of the INSERT INTO command happened (maybe a power cut) all I know is that removing it caused AMTU to work ok again.
Hope this helps someone else in future!
So glad I found this thread. I'm having the same issue - except, my smaller files work fine - but it's the larger ones that won't go through. I have a 16MB file (.txt) that gets stuck in the /temp folder.
The audit logs never show that it's transmitted at all - there is NO MENTION of it in the audit logs anywhere. Other, smaller files are going through fine.
Can someone give me a simple, step-by-step on what to edit to allow the bigger files?
I'm Back - Amazon Tech Support redirected me here, which is funny, since I was already the last person to post.
I've done all the changes mentioned above ... My smaller files (ie. 9MB) get processed perfectly.
I have two VERY LARGE files - a 64MB inventory .txt file, and a 160MB .txt file.
Neither of these get out of the /temp folder. AMTU never even shows them in the audit log ... there is no mention of those filenames in the audit log at all.
I'm getting warnings from Seller-Performance about my cancellation ratio, and it's driving me crazy, because nobody can seem to explain why I can't get my inventory updated.
I fear this thread is dead - no replies since last year?
Looking through old forum posts:
Seems to indicate that 5MB is about the optimum size for a file and these guys had trouble with > 15MB.
I haven't run this app in a VERY long time, but am willing to bet that splitting them up into several 5MB chunks will be a more effective way of ensuring they all get through.
Thanks, Jeremy -
I was trying to avoid the manual labor of having to break up the file (I download it from my inventory provider) every day for the upload process - but it seems as if I have no choice.
I'm having a similar issue, but increasing the heap size has not addresses this.
However what I have narrowed the cause to is that once a file increases to a size meaning that it cannot be posted within the 5 minute posting period, AMTU will forget about the file that was in progress of being posted.
It would seem that making files smaller will not solve this issue either, since if you try to sumbit multiple files inside the 5 minute period, AMTU will forget about whichever it was processing after 5 minutes. To make this work, the second file would have to be held outside of the outgoing directory until the 1st file has completed posting.
A workaround would be to perhaps increase the polling period from 5 minutes, but I cannot find a way to configure this, does anyone know of a way to do this (except for a recompile of the source)?
If this code is still being maintainced, the correct solution would probably be to delay the posting if another post was already in progress. Does anyone know if AMTU is currently being developed?
I've had the same problem again since I last posted - twice.
Each time the same syptoms - files are deposited into the outgoing folder, AMTU moves them to the temp folder, and there they stay.
Each time I've been able to nudge a couple more days use out of it by reducing the file sizes to half - but evntually it stops again.
I've found, that the quickest way to resolve this issue is to uninstall AMTU using the UNISTALL.BAT file, deleting everything in the Merchant Transport folder (except the document transport folder), and reinstalling from the exe.
It takes 5 minutes and sorts the problem for another 6 months.
Replying to the above poster who was sending 160mb + files - I'm sure I've read that 10mb is the maximum file size for one post. Also - it must be taking many hours to process. Consider XML as it's much much faster,and you only send updates for the price and stock- not the entire product. We used to use text files and for example 10,000 product updates with text files took about 4 hours to process. XML can do the same updates in 20 minutes or so.
I guess this is a limitation of AMTU - it can only handle so many uploads/downloads before it's logfiles/datafiles get too large.
Now I'm waiting for the Amazon Merchant Web Services to be launched in the UK - then we can get rid of AMTU.
Hope this helps,
another update - it just happened again and the advice on uninstalling / reinstalling just needs to be updated to say make sure you keep a copy of the JRE folder - since the previous java update.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.