A few Kb was just a joke. But with messages 100kb ++ and 10-15000 messages a day the server did malloc quite often...
This was on solaris with oracle. -- Jarl On 6/11/07, Grooms, Frederick W <[EMAIL PROTECTED]> wrote:
Jarl, What platform are you on? I routinely have 60 - 100 Kb XML transactions with no memory errors. (I am on Sun with Oracle) Fred -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Jarl Grøneng Sent: Saturday, June 09, 2007 12:57 PM To: arslist@ARSLIST.ORG Subject: Re: Hypothetical AR Server as middleware? Huh, it cant handle larger xml than a few Kb. Storing XML in a database as tables and fields(like its done in AR System) are not the prefered method when talking about performance. We all love the Malloc 300 errormessage when using webservices.... -- Jarl On 6/9/07, Chris Woyton <[EMAIL PROTECTED]> wrote: > Here's an opposing thought worth considering... > > Going back to the spirit of ARS being a Rapid Development Platform, > why would BMC encourage development of the *same thing* that's out > there already, regardless of who produced it? Many have lost sight of > ARS as a development medium because it's been perceived as "just a > Help Desk" for quite some time - and adding 50 more flavors of IT > Request/Service Management won't do much to fix that perception. > > Requiring partners to produce products that are in non-competition is > certainly part of the goal - money drives everything, as they say. > However, it may also be construed as pushing the horizontal boundaries > of the platform - pushing ISV's to take the product and move it into other arenas. > There's obviously some interest in taking advantage of this facility, > so instead of ITSM-esque applications, how about Fleet Management, > Document Management, Middleware (Web Services + ARDBC + Workflow > Engine is a dynamite combo for this), Financial Applications, etc. > > IMHO, those things add value to the platform - another ITSM product doesn't. > A bigger pie provides revenue to BMC, no doubt, but it also gives the > ISV a chance at more than crumbs. > > -Chris Woyton > ATS, TuringSMI > > ps with regards to Robert's comment on CMDB, another thought comes to > mind - I've often pondered using the OBJSTR sub-system as a > development medium all on its own. Imagine this - you build a core set > of Classes for a particular use, for example, > Middleware/Data-Transfer. When a new Data Source becomes available, > specialized a Sub-Class for it. Consumers of the data can then point > to the specific Sub-Class or the root Parent Class (or at any point in > the tree) depending on what data they need to use. Or, in a Request > Management application, rather than providing different "Views" of an > app to suit different groups, specialize a Sub-Class for that Group > such that common data is shared, but specific data is segmented. Data > sets could be used to support Tenancy in a model like this and the Recon Engine could facilitate inter-application integration (as well as exta-application). > > Maybe one of you hyper-motivated young guns can play with that idea > (Reinfeldt already busts my chops for the 30 or so half-written emails > to him I haven't had time to finish, so no way would I commit to > prototyping that stuff..hehehe) :) > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] Behalf Of Robert Molenda > Sent: Thursday, June 07, 2007 9:27 PM > To: arslist@ARSLIST.ORG > Subject: Re: Hypothetical > > > Axton - you think too much outside the box :) Just like so many of us > on this list :) :) We need more of this thinking again!!! > > I have actually been wondering about this for some time now, > especially in the area of CMDB and 'Re-development' or 'Module > Integration' so to say. > > The BMC CMDB while being 'OK' (not to take this completely off topic) > is such an overhead that a much simpler and "customer fitting design" > would be so much more performant to the ARSystem and other applications... > (none the less cheaper and easier to maintain at times!) > > At what point will BMC begin to limit customizations? Imagine if the > install of say Incident Management installed all objects in "Locked > Mode"... > > I wonder at times if BMC forgot the first envisioned cause for ARS... > Rapid Application Development, Flexible Workflow, ... > > Robert > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook > Sent: Thursday, June 07, 2007 6:28 PM > To: arslist@ARSLIST.ORG > Subject: Re: Hypothetical > > I don't know what BMC's criteria are for approval, but I do know that > there are already competing Service Management products out there, > what's the point of a few more, unless someone thinks they've > architected the code better than BMC does? > > Rick > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Axton > Sent: Thursday, June 07, 2007 4:24 PM > To: arslist@ARSLIST.ORG > Subject: Re: Hypothetical > > hmmm... probably if you write it first and big brother likes it, > you're SOL. > Prepare to be bought or dropped (aka, prepare to be boarded)? I guess > there's money to be made there, but geez, what a disappointment... > > Axton Grams > > On 6/7/07, patrick zandi <[EMAIL PROTECTED]> wrote: > > ** > > Woo, So first inventor win's ? as long as you pay and have it locked. > > > huh .. > > Land Grab.. > > > > > > On 6/7/07, Axton <[EMAIL PROTECTED]> wrote: > > > > > > Just a hypothetical question. > > > > > > Deployable applications, which include the ability to enforce user > > > fixed/floating licenses, are available to partners/ISVs. > > > > > > Partners are not allowed to write competing products. > > > > > > Does this mean that companies/people attempting to write apps that > > > are similar in nature to those that Remedy offers are in a catch22 > > > situation? > > > > > > Axton Grams > > > > > > > > > > -- > > Patrick Zandi _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
