If an article fails to finish uploading, you should delete it and add it again. Have you tried that?

Tony and others,

In addition to the spinning cursor, we added a logging mechanism that can be optionally enabled to help us get better insights into where these upload processes are getting stuck.  If any of you who are consistently experiencing this problem are willing to create and provide such a log, your efforts would be very much appreciated.

Here are the details of how to activate the logging mechanism:

By default file logging is disabled in the DMP Panel, an end-user can enable it by adding a log_config.xml file to their Local Store “dmp” folder (e.g. "/Users/your_name_here/Library/Preferences/StageManager.BD092818F6728 0F4B42B04877600987F0111B594.1/Local Store/dmp/") and restart the panel.

Once enabled, a “debug.log” file will appear in the same folder when the panel outputs logging info. Log messages are cached in memory and flush to the output file after we reach the max limit (currently we cache up to 10 log statements). So you do not necessarily see all the logs if you examine the log output file during execution. All in memory logs are flushed to output file when you close the panel. The log file size can never excess 200 kb. New log entries are appended to the end of the file and when the file size gets too large, it is truncated leaving just the last 100 kb before appending the new log entry to the end.

Below I will append the necessary contents of the log_config.xml file.  You can send the results off forum to me at the address below.

Thanks,

Michelle

mdalton@adobe.com

Required contents of log_config.xml

<?xml version="1.0" encoding="UTF-8"?>

<!--
ADOBE SYSTEMS INCORPORATED
  Copyright 2011 Adobe Systems Incorporated
  All Rights Reserved.

NOTICE:  Adobe permits you to use, modify, and distribute this file in accordance with the
terms of the Adobe license agreement accompanying it.  If you have received this file from a
source other than Adobe, then your use, modification, or distribution of it requires the prior
written permission of Adobe.
-->

<config>
<logTarget>
  <!-- The log target type. Supported types are "TRACE_TARGET", "FILE_TARGET" -->
  <targetType>TRACE_TARGET</targetType>
  <filters>
   <filter>com.adobe.dmp.*</filter>
  </filters>
  <!-- The log level to restrict amount of logging message. All "higher" level messages than specified level here are logged
    ALL(0), DEBUG(2), INFO(4), WARN(6), ERROR(8), FATAL (1000)
    -->  
  <level>0</level>
  <!-- Enable/Disable this log target, the default value is true -->
  <enable>true</enable>
</logTarget>
<logTarget>
  <!-- The log target type. Supported types are "TRACE_TARGET", "FILE_TARGET" -->
  <targetType>FILE_TARGET</targetType>
  <!-- File log target needs to provide name of log file -->
  <filename>debug.log</filename>
  <filters>
   <filter>com.adobe.dmp.*</filter>
  </filters>
  <!-- The log level to restrict amount of logging message. All "higher" level messages than specified level here are logged
    ALL(0), DEBUG(2), INFO(4), WARN(6), ERROR(8), FATAL (1000)
    -->  
  <level>2</level>
  <!-- Enable/Disable this log target, the default value is true -->
  <enable>true</enable>
</logTarget>
</config>

The current logging starts after login and focuses on the upload/update process itself.

Given recent inquiries about login failures we are looking for opportunities to extend the logging to include those code paths.  In the meantime engineers are evaluating logs from network protocol sniffers such as Charles to look at those scenarios.  I recall that you are already directly in contact with Nethra for such an evaluation.

Michelle

mdalton@adobe.com