[
https://issues.apache.org/jira/browse/TRINIDAD-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420940#comment-13420940
]
Kentaro Kinebuchi commented on TRINIDAD-2293:
---------------------------------------------
In my specific example the cost of replicating file A is trivial since the file
presumably exceeds org.apache.myfaces.trinidad.UPLOAD_MAX_MEMORY so the cost is
just the replication of a single String denoting the path to the temporary file
location. However, there is a cost in the case the file is smaller than
org.apache.myfaces.trinidad.UPLOAD_MAX_MEMORY. In that case, it would replicate
the in-memory file itself and UPLOAD_MAX_MEMORY has a default value of 200KB so
the cost is 200KB.
The current code does not suffer from race conditions and this code doesn't
result from session key clashes because we do not do handle more than one
simultaneous upload request at a time, regardless of how many separate upload
components we have and how many we have started uploading from. All subsequent
upload requests are queued and are processed one by one.
If we ran the lifecycle on file A after it completes and then ran the lifecycle
on B again later then we'd have consecutive single file uploads rather than a
multi-file upload. The reason why we have "multi" file uploads is because we
are running the lifecycle on A and B in the same request.
Regarding the server crash during an upload, that is a good point. That is one
scenario which is not covered by the fix (and cannot be reasonably covered by
any fix). However, I think in that scenario there is less chance of the user
getting confused because the file upload would Fail as soon as the server goes
down so it would be obvious to the user that something bad happened which
requires the file to be re-uploaded. What is bad for the user about my example
is that the user sees the Failure only after submit rather than during upload.
> multi file upload does not get replicated in a High Availability environment
> ----------------------------------------------------------------------------
>
> Key: TRINIDAD-2293
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2293
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Infrastructure
> Affects Versions: 2.0.2-core
> Environment: linux x86
> Reporter: Kentaro Kinebuchi
> Attachments: Trinidad-2293.patch
>
>
> In multi file upload, the uploaded files are stored in the user's session
> before submit. In a HA environment, the session context which is replicated
> does not contain this file information so if the server goes down then the
> file data is lost in the replicated server.
> There are two specific issues which need to be handled in the code:
> 1. In WebLogic, unless the setAttribute() method is called on the session
> context, that attribute is not automatically replicated. Hence, all
> attributes which are updated during multi file upload and we want replicated
> have to specifically call that method.
> 2. WebLogic does not replicate all File objects stored in the context. Hence,
> the path to the temporary file created for each uploaded file needs to be
> saved in a String in the context so it is replicated.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
