Its only showing 100-200 used ORB connections @ a time, though, and
the file read/write is done sequentially for each client, so its
really only 100-200 open @ a time, I think. All 1,000 aren't
accessing it @ once.
Plus, I did a "zpool iostat" on the file system and the r/w metrics
aren't very high @ all.
What's an MDB?
On Jan 18, 2008 2:32 PM, <glassfish_at_javadesktop.org> wrote:
> Oh, I can see "1000's of clients" blasting things like number of open files etc. in to shiny bits.
>
> Now, in theory, you're not supposed to use file.io from an EJB, but every one does anyway. This limitation is mostly inspired by the fact that Files aren't clusterable, you "don't know" where the ejb is really deployed, etc.
>
> However, opening a 1000 files tends to send most processes in to fits, so if you're turning things around that fast, you could be running in to that.
>
> Another thing that you could try is (depending on size and such) is dumping all of the requests in to a queue, and using MDBs to pull them off and save them to the server. If you have only 10 MDB instances reading the queue, you'll only have 10 files open at one time vs 1000s.
>
> This can be a mechanism that allows you to throttle the demand on the file server, while still serving up the clients. There may be a delay between when the request returns to the client and when the file shows up on the final server, but if that's not an issue, then this can work really well.
>
> Also, assuming you're using a persisted message store (that's by default), then your messages are "saved" at transaction commit, even if they're not on the back end yet (They're stored in your queue -- not the most accessible place, but they're reasonably safe there.)
>
> Then, if your MDB has problems saving the file, the queue can retry or you can send the files to a "dead letter"queue for safe keeping to be handled later.
>
> Anyway, that kind of architecture may work for you as well, and still be able to use files.
> [Message sent by forum member 'whartung' (whartung)]
>
> http://forums.java.net/jive/thread.jspa?messageID=254759
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>