|
Home > Archive > WebSphere Portal Server > March 2005 > WP5 Sharing file uploads across WP Cluster
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
WP5 Sharing file uploads across WP Cluster
|
|
|
| I have a portlet that handles File Upload of optional attachments (input
type="FILE") along with other form data that the portlet processes. This
portlet processes the form data, and moves the optionally uploaded file
attachment to a servable content area of the exploded portlet WAR, such that
it can be downloaded from a browser via simple URL to that content.
I have a second portlet that displays some data based on the original POSTed
data above, and if there was an attachment, it shows a URL to that content
(with a URL directly to the content and a target=_blank so you get a request
from a new browser to the file itself, while the original browser stays at
the portal)...
Anyway, that all works fine in a single WP Server instance scenario, but now
someone wants to use these portlets in a WP cluster (multiple WP servers
possibly on different boxes). The above won't work as is in that env
because the uploaded file is simply a file within the servable content area
of the installed portlet WAR - that portlet WAR on other servers in the
cluster would not have a copy of that file).
- One option is to have the upload portlet copy it to a shared filesystem
that the others can get at or to the other portlet wars, but that's a bit
less than ideal
- Another option is to store the uploaded file data to a DB BLOB/CLOB and
serve it up from there (eg, from a servlet in the portlet WAR) instead of
from simple files in the servable area of the portlet WAR(s).
- Yet another option MAY be to use some form of WP document management API
to allow me to store the uploaded file in an area managed by WP that all
servers in the cluster can then serve the file out of.
I don't know much about WP content mgmt, but I have seen that there's
something called WPCP, and then WP5.1 docs talk about Document Manager, and
then there's Workplace Web Content Mgr and various other Content Mgmt
solutions/add-ons. I've only seen admin/doc-mgmt portlets with these
though, not simple APIs for storing a file that my portlet already has its
hands on, to someplace that all copies of my portlet WAR in the cluster can
then access.
- I don't want a full-blown CMS for this - and I don't need other CM/DM
admin portlets, but rather just an API for putting uploaded content (that my
portlet manages the upload of) somewhere where it can then be fetched via
URL (as content in a new browser window, not within a portlet view) from the
other portlet WARs (thus, someplace where my display portlet can build a
content URL to it from any WP instance in the cluster). Do any of the WP
"BUNDLED" doc management facilities provide such an API (without requiring
extra CMS overhead/administration/processes) or should I stick to the DB
option above?
Thanks for any info/insight you can provide...
| |
| Michael Harris 2005-03-07, 5:56 pm |
| What's the lifecycle and scope of the uploaded files?
For example, if the uploaded files were only used by a single user at a
time and they only remained for the duration of the user's session (as
might be the case in an e-mail client) then you could consider keeping
the bytes of the files in the session object in memory. Since the
session is clustered, the data would be shared among servers in the
cluster. I think the JSR168 API allows you to share the session object
between a portlet and a servlet in the same .war file. The servlet
could serve up the bytes of the files if needed. If you are using the
IBM portlet API, there are undocumented ways to share the session, but
it is not supported. WAS also has a class called DistributedMap that
may be of help too.
| |
|
| Sorry, this is not just for a single user for a single session, otherwise I
would have no need to upload the files - there is no processing done on the
files on the server, they're just there for other users to download. The
first portlet is used by an application admin (eg, your manager, not
necessarily a portal admin) to upload some information to notify other users
about (eg, likely stored in a database) and an optional file from their
desktop associated with that information (eg, MSWord, PDF, etc). The
second portlet is used by the rest of the users to receive/display/read
information uploaded by the manager, and if there was an attachment uploaded
with that information, then to be able to click on a link which downloads
that attachment into a new browser window (eg, to read a word or pdf or text
document associated with the otherwise simple text info).
I'm beginning to think that storing these optional file attachments in a DB
BLOB with the rest of the associated form info would make more sense, rather
than taking on the overhead of a content management system for such a simple
and optional use of uploaded/downloaded files...
"Michael Harris" <none@none.com> wrote in message
news:d0ihb5$3hr8$1@news.boulder.ibm.com...
> What's the lifecycle and scope of the uploaded files?
>
> For example, if the uploaded files were only used by a single user at a
> time and they only remained for the duration of the user's session (as
> might be the case in an e-mail client) then you could consider keeping
> the bytes of the files in the session object in memory. Since the
> session is clustered, the data would be shared among servers in the
> cluster. I think the JSR168 API allows you to share the session object
> between a portlet and a servlet in the same .war file. The servlet
> could serve up the bytes of the files if needed. If you are using the
> IBM portlet API, there are undocumented ways to share the session, but
> it is not supported. WAS also has a class called DistributedMap that
> may be of help too.
| |
| Editor 2005-03-18, 6:00 pm |
|
>I'm beginning to think that storing these optional file attachments in a DB
>BLOB with the rest of the associated form info would make more sense, rather
>than taking on the overhead of a content management system for such a simple
>and optional use of uploaded/downloaded files...
>
>
>
>
We have a similar situation with an application that stores images. We
opted to store them on the file system. On windows you can just use unc
paths and in unix you could use nfs/afs or some other "shareable" file
system
|
|
|
|
|