Re: [OTRS] JavaScriptError: Cannot call method 'Init' of undefined

Yeah! The ticket number generation. Forgot about that. That's also
using the file system; using a database is the much saner choice for
that. If you could share the code I'm sure people would be interested.

If you're using 3.0.6 I'd really recommend you to upgrade your OTRS
version; newer versions run much more efficiently.

The otrs.LoaderCache.pl script uses a new function from
Kernel::System::LoaderCache and in OTRS 3.3 this uses the new object
loader mechanism. You can't just copy the files and expect it to work;
it would need a little backporting effort.

--
Michiel

On Fri, Apr 10, 2015 at 8:47 AM, Ali Umair <[email protected]> wrote:
> Michel,
>             If i run otrs.LoaderCache.pl of otrs 3.3.5 on my current version
> otrs 3.0.6. then this cache problem is fixed or i need do change something
> more than this???
>
> Actually from my analysis for otrs running on two nodes (request balancing
> through F5) hurdle is ticket number generation which on TicketCounter log of
> the file system. I move the logic of ticket number generation from file
> system to database. Now both nodes get ticket number from database. i have
> code for this if you need i can share.
>
> Ali
>
> On 4/9/2015 5:38 PM, David Boyes wrote:
>
> Which ' local file system'  references are you talking about?
>
> Any time the code refers to a file on disk for configuration or operational
> information instead of the database. My goal was to have the entire OTRS
> system code (with the exception of the data it operates on) to be read-only.
> I operate environments where truly read-only code can be efficiently
> physically shared, and I wanted to take advantage of that.
>
> There are just a few places where OTRS uses local file systems (session
> storage, attachments, VirtualFS which is used by Change
> Management) and all these also have options to use a database backend.
> Apart from that, there is the loader cache for which there is the
> '--generate'
> option now.
> There is also the SysConfig which is stored in a file on disk.
>
> Yes. Recent versions of the OTRS code are much, much better about not
> storing node-specific code elements in external disk files (thank you!),
> which is why I said my code would need updating. You weren't as careful
> about that in earlier releases.
>
>
>  Did you store the minified JS and CSS files in the database? And the
> SysConfig values? that's nice but it might be a little bit over-engineered.
>
> OK. If it's not useful, then no harm done. I think at least the parts that
> move sysconfig data into the database would be useful (one of the most
> common problems I see here is caused by not regenerating that cache file),
> but no big deal.
>
> Also,
> the vast majority of OTRS users will not need clustered setups, and will use
> vertical scaling  - bigger machines - or maybe break out the database server
> to a separate machine, and avoid all headaches that come with multiple
> master nodes.
>
> Here I would disagree. As people virtualize more and more of their
> infrastructure, there is significant hard data that small numbers of bigger
> machines perform much more poorly than multiple smaller machines and are
> much harder to tune for performance. It takes a lot more work for a
> hypervisor to manage a few big machines than multiple smaller machines
> (especially on Intel architectures which are not optimized for this kind of
> thing). Consider page table mapping, swap infrastructure for large VMs and
> balancing in-memory vs file caching for big machines when you need to bring
> substantial numbers of pages in and out before a machine can be dispatched
> efficiently. It really does work out better in terms of system overhead in a
> shared resource environment to have a horizontally scalable design than a
> vertically scaled one. You also gain a measure of HA design that allows
> concurrent maintenance if done properly (another common problem seen here is
> not having a way to do rolling up
>  grades to avoid outages, which really needs to be present for
> enterprise-grade services).
>
> Definitely break out the database server in any case, but I'd argue much
> more strongly for well-behaved cluster performance than just throwing
> hardware at the problem. Horizontal and vertical scaling aren't mutually
> exclusive if you design for them properly.
>
> _______________________________________________
> OTRS mailing list: dev - Webpage: http://otrs.org/
> Archive: http://lists.otrs.org/pipermail/dev
> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev
>
>
>
> --
>
> --
>
> Best Regards
>
> Ali Umair | Software Engineer
> i2c Pakistan | 04-Old FCC, Ferozepur Road, Lahore, PAKISTAN
> Ph: 0092-42-111 000 911 X 171 | Cell: +92-334-4556898
>
>
>
> _______________________________________________
> OTRS mailing list: dev - Webpage: http://otrs.org/
> Archive: http://lists.otrs.org/pipermail/dev
> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev
_______________________________________________
OTRS mailing list: dev - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/dev
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev