This seems to me like a HUGE problem. I'm simultenously relieved that its not in my code, and horrified that its inherent to Orion, since this may rule out the possibility of using Orion in production. I'm not sure how a problem like this could've made it out of the QA cycle! In my opinion, setting timeout levels to be very short is a work-around and not a fix. Also, it doesn't fit all business models.
I sincerely hope the Orion team is working hard to fix this bug... I don't know how Orion can be called "robust" when this sort of thing can happen.
-Dan
Marcus Ahnve wrote:
> "Juan Lorandi (Chile)" wrote:
>
> yes, I've been complaining about this issues starting a month ago...
> check bugs #161 & #170 for more info
>
> nobody from orion replies, and it's a shame, because I can´t license
> the products until I work my way around these
>
> Anybody performing a DoS attack on any Orion Web Site will effectively
> crash the serverBug #170 was filed due to the fact that the server chrashed and burned
if it ran out of connections. For some weird reason, it seems to be very
CPU expensive to wait for a connection. However, now that you can
specify the wait-timeout property we can keep the server alive, with
tons of timeouts though. I've set the status of #170 to fixed, since the
immediate problem is fixed. Now, for "DataSource not closed", that's a
whole new story, but I believe that there are other reports in bugzilla
regarding that topic. FYI, we not only get it due to timeouts, but when
testing our app against Hypersonic's in-memory db too. No clue why./Marcus
--
Marcus Ahnve email: [EMAIL PROTECTED]
Lecando AB Office: +46-(0)8-634 94 18
Sweden Mobile: +46-(0)70-462 19 18
www.lecando.com ICQ#: 4564879
-- Daniel G. Koulomzin Digital Media On Demand 244 Brighton Ave. 3rd Floor Allston MA 02134
