• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Jeanne Boyarsky
  • Liutauras Vilda
Sheriffs:
  • Rob Spoor
  • Bear Bibeault
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Piet Souris
Bartenders:
  • Frits Walraven
  • Himai Minh

Tomcat server modification 9 and 10

 
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I recently have got to the base construction of an idea I had a decade back to prevent disc head read crowding and blocking by keeping all commonly used files ready on an array as bytes inside server RAM.
The Ramfile object is accessed through an interface apart the fact it is also bound into the ApplicationContext e.g  also called through ServletContext
It's reasonably simple to use and not too complex to fit into a Tomcat

API docs for its interface
https://www.scribd.com/document/472437350/javax-servlet-Ramfile-Javadoc

Source code
https://www.scribd.com/document/470554983/javax-servlet-Ramfile-Interface-and-org-apache-catalina-core-RAMfileArray

Any sensible criticism or suggestions. .
 
Saloon Keeper
Posts: 23689
161
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm curious why this special mod specifically for Tomcat. RAMDISKS have been a thing for a very long time now. Indeed, all the major Linux distros employ a RAMDISK as part of their secondary boot process. It loads in the live kernel and resources.

Then there's caching. Modern hard drives have multiple gigabytes of on-board cache. OS's have lots of filesystem cache - probably a third or more of the physical RAM on my machines is cache.

Web systems have cache of various forms, such as SQUID and REDIS.

So it would be interesting if you could show us some use cases where all that hard work gained you something significant (other than Tomcat expertise, of course), Benchmarks would be especially useful.

Oh, and since this is Tomcat-specific, I'm adding this thread to the Tomcat forum where the people most likely to benefit hang out.
 
Samuel Marchant
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Holloway wrote:I'm curious why this special mod specifically for Tomcat. RAMDISKS have been a thing for a very long time now. Indeed, all the major Linux distros employ a RAMDISK as part of their secondary boot process. It loads in the live kernel and resources.

Then there's caching. Modern hard drives have multiple gigabytes of on-board cache. OS's have lots of filesystem cache - probably a third or more of the physical RAM on my machines is cache.

Web systems have cache of various forms, such as SQUID and REDIS.

So it would be interesting if you could show us some use cases where all that hard work gained you something significant (other than Tomcat expertise, of course), Benchmarks would be especially useful.

Oh, and since this is Tomcat-specific, I'm adding this thread to the Tomcat forum where the people most likely to benefit hang out.



It's for lowering processing time and lowering disc io.

It is NOT a Linux ramdisk !
It is not a server disk buffer cache !
It is not not not for text pages such as jsp that are processed or given time based termination headers.
However large static no-cache expires now pages of html XML could be placed on it if used often, and pre encoded base64 text as bytes for email attachment handling or rather than obtaining commonly used base64 encoded images from databases.

It is with the Tomcat startup Java command line configured for memory to gluttonise RAM memory for objects resulting in no need for disc I/O to acquire the bytes of files for requests.
The use case scenario is older slower machines that continually get large hits for particular downloads or the many images that fit the site style GUI and are present every page - this last you should be aware of headers in HTML no-cache and expires now.
Downloads of documents are also a heavy disc Io hit.
Some assessment of expired previously sent files in systematics would be an issue but until you prevent disc Io it blocks / lowers performance.

In essence J2EE servers internals are quite similar so i'll add it into a glassfish when I get around to it.

When you say gb's disc cache you mean "a type of RAM" alike Superdome or SSD?

Anyhow, I don't know of any explicit object in the J2EE server API that does this handlable at such proximity to the programmer for such purpose of either action or control in applications, such things are relegated to pure add in and or configuration of the server.
This makes it a class and interface alike Servlet and GenericServlet not some weird or hidden underpinning of configuration.
 
Tim Holloway
Saloon Keeper
Posts: 23689
161
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't know what you mean by "gb's disc (sic) cache". If you're refering to the physical cache on disk drives, They do, in fact come with significant RAM on the controller board, allowing the device to be complete write operations rapidly and to retrieve commonly-accessed data without having to wait on physical disk latency.

Squid is just one of many products that can cache static page responses in RAM when used as a proxy for Tomcat. There are also physical boxes that provide front-end caching, although unless you're a big IT shop, it's usually cheaper to use a software cache.
 
Samuel Marchant
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Holloway wrote:I don't know what you mean by "gb's disc (sic) cache". If you're refering to the physical cache on disk drives, They do, in fact come with significant RAM on the controller board, allowing the device to be complete write operations rapidly and to retrieve commonly-accessed data without having to wait on physical disk latency.

Squid is just one of many products that can cache static page responses in RAM when used as a proxy for Tomcat. There are also physical boxes that provide front-end caching, although unless you're a big IT shop, it's usually cheaper to use a software cache.



This system is part of the J2EE server and user agents can simply have an http cache header sent with i.e. images for staleness expiry.
That keeps innumerable calls to the disc and hardware bus out of the way of heavy ram(in the long run the Ramfile system is better) and bus and disc head track consumers such as databases
 
Tim Holloway
Saloon Keeper
Posts: 23689
161
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Some pusillanimous pedantry:

A "disk" is a hard drive or other fixed media.
A "disc" is a CD, DVD or other removable media.

It's not logical, but that's the way it is.

Just to repeat, though, a data request isn't going to get anywhere near a disk drive's read/write heads unless the data could not be found in either the OS buffer cache or the physical drive's on-board RAM.

The primary use of cache software is to fine-tune the process. For example, if a front-end cache utility keeps a popular javascript or CSS file as compressed data in RAM, the act of locating it in cache, expanding it and transmitting it could well be much faster and more RAM-efficient that relying on the OS buffers. I was actually shown a case where that had been taken advantage of way back in the 1970's. And it wasn't even a very efficient compression scheme.
 
Samuel Marchant
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Holloway wrote:Some pusillanimous pedantry:

A "disk" is a hard drive or other fixed media.
A "disc" is a CD, DVD or other removable media.

It's not logical, but that's the way it is.

Just to repeat, though, a data request isn't going to get anywhere near a disk drive's read/write heads unless the data could not be found in either the OS buffer cache or the physical drive's on-board RAM.

The primary use of cache software is to fine-tune the process. For example, if a front-end cache utility keeps a popular javascript or CSS file as compressed data in RAM, the act of locating it in cache, expanding it and transmitting it could well be much faster and more RAM-efficient that relying on the OS buffers. I was actually shown a case where that had been taken advantage of way back in the 1970's. And it wasn't even a very efficient compression scheme.



Not my view of caching based on http headers expire and cache-control particularly the parameter "stale".

it does serve purpose as it is built into a J2EE server for caching headers such as expires , Etag if-none-match 304, max-stale , max-age, these used deregate the theory of commonly used by request count for caching and these are stored in objects in the RAM.

because it lowers disc IO operations and lowers hardware BUS hops.

It can be described as a J2EE implementation of  
caching.
 
Tim Holloway
Saloon Keeper
Posts: 23689
161
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I still don't understand why you're so adamant that the physical disk hardware is going to get involved. Modern OS's do actual physical disk I/O reads only as a last resort. If the data was recently referenced, the OS will pull it straight out of physical RAM. Not Virtual (disk-based) RAM, but actual physical RAM. No spin latency, no head activity. no grabbing the I/O buses. And that data is not discarded from RAM unless more recent requests crowd it out. My desktop is currently using over 1.5GB of buffer memory and I haven't even tuned it.

The best place to check for expired headers in any event is on the client side. Since a network request from the client generally has far more overhead and delay than a local disk request. To say nothing of eating into total network bandwidth. Regardless, protocol-aware caching proxies (like Squid) do pay attention to the headers. You can do a lot of fine-tuning on a product like squid if you need to. I use Squid as an example since I run it to cache OS update packages. Small packages cache in RAM, larger ones on disk, but regardless, I only have to pull the package once from the (slow) Internet, and thereafter all the proxied servers can get their OS updates via Gigabit internal networking. That's forward proxying, but Squid also does reverse proxying.

Not to shred your hard work, and I'll give you marks for digging into Tomcat/JEE, but to award major-league geek points, I'd want to see tangible benefits. That is, benchmarks and supporting documentation. The problem with what efficiency-gaining mechanisms are "supposed" to do is that I can personally attest - with support from other long-timers here - that the inefficiencies in a system are almost never where you "know" they're going to be. Time and again we've seen that when actual measurements are made that the real bottlenecks are somewhere else.

Just one example: Many years ago I was part of the OS support group for a large IBM mainframe. It started crashing every afternoon about 3 PM. If you have never worked with mainframes, mainframe computers are never supposed to crash. You don't just "turn a mainframe off and back on again". For one thing, system startups could take 15 minutes or more and the entire company could come to a halt. The cure wasn't in changing software in that particular case, just a single option switch that had to be set properly on one of the remote terminal systems.
 
Samuel Marchant
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Holloway wrote:I still don't understand why you're so adamant that the physical disk hardware is going to get involved. Modern OS's do actual physical disk I/O reads only as a last resort. If the data was recently referenced, the OS will pull it straight out of physical RAM. Not Virtual (disk-based) RAM, but actual physical RAM. No spin latency, no head activity. no grabbing the I/O buses. And that data is not discarded from RAM unless more recent requests crowd it out. My desktop is currently using over 1.5GB of buffer memory and I haven't even tuned it.

The best place to check for expired headers in any event is on the client side. Since a network request from the client generally has far more overhead and delay than a local disk request. To say nothing of eating into total network bandwidth. Regardless, protocol-aware caching proxies (like Squid) do pay attention to the headers. You can do a lot of fine-tuning on a product like squid if you need to. I use Squid as an example since I run it to cache OS update packages. Small packages cache in RAM, larger ones on disk, but regardless, I only have to pull the package once from the (slow) Internet, and thereafter all the proxied servers can get their OS updates via Gigabit internal networking. That's forward proxying, but Squid also does reverse proxying.

Not to shred your hard work, and I'll give you marks for digging into Tomcat/JEE, but to award major-league geek points, I'd want to see tangible benefits. That is, benchmarks and supporting documentation. The problem with what efficiency-gaining mechanisms are "supposed" to do is that I can personally attest - with support from other long-timers here - that the inefficiencies in a system are almost never where you "know" they're going to be. Time and again we've seen that when actual measurements are made that the real bottlenecks are somewhere else.

Just one example: Many years ago I was part of the OS support group for a large IBM mainframe. It started crashing every afternoon about 3 PM. If you have never worked with mainframes, mainframe computers are never supposed to crash. You don't just "turn a mainframe off and back on again". For one thing, system startups could take 15 minutes or more and the entire company could come to a halt. The cure wasn't in changing software in that particular case, just a single option switch that had to be set properly on one of the remote terminal systems.



A server is not committed when it starts with the settings of the OS, as that being of reference to your "desktop and 1.5gb" that numeric is only relevant if you also give the total RAM size of the machine with it, I presume makes 1.5gb small and irrelevant.
Some of the smaller 2gb  and 4gb desktops will be just fine for a Tomcat in someone's small business but may need the database with it.
Tomcat itself only allows 1gb max RAM on one of its reserves on the command line the other two are smaller assignment again, so I don't see where it will get either RAM or bus and head time from for requests.

Servers don't check clients cache they send initial data and caching headers for the output information, as of proxy cache , in http 1.1 if the cache is set private the proxy will have no contact with the client data and it's controls, for a proxy to cache the data must be set public (http 1.1 cache -control header) as every government that is not USA or Russia stipulated for internet cafes.

Betca' !  quite true I would never listen to stopping work on this because it is a matter of header data optimising the information conjunct to ready fast easier handling and as an option that previously did not exist.

 
Tim Holloway
Saloon Keeper
Posts: 23689
161
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
English doesn't appear to be your native language, I can't always tell what you're really saying. So forgive me if/when I mis-understand.

Samuel Marchant wrote:
A server is not committed when it starts with the settings of the OS, as that being of reference to your "desktop and 1.5gb" that numeric is only relevant if you also give the total RAM size of the machine with it, I presume makes 1.5gb small and irrelevant.



I don't know what "commited" is or whether you mean the host machine (physical server) or the Tomcat server. People often lose the distinction. However at a rough guess, let me say that specifically in the case of Linux, the Linux OS partitions memory at boot time. It has a fixed amount for the kernel (non-pageable) code and data, it has a dynamically-computed virtual memory support pool. And it has a dynamically-computed non-pageable I/O buffer area. Depending on the OS release, distribution, and tuning parameters, the size ratios of these last two areas may vary, but by default, the buffer space tends to be fairly large. I don't guarantee that the OS won't dynamically adjust sizes based on detected loads. It probably does.  Windows has similar mechanisms, although they tend to be more mysterious. Open-source OS's are great because if the original development team doesn't bother to document something, chances are that some frustrated user will figure it out and publish the information.

Incidentally, if you cache stuff in user RAM, remember that that's virtual memory and thus subject to paging. Which brings in all that physical disk delay in by the back door. You'd have to page-lock the affected memory or allocate out of a non-pageable RAM space to avoid that.

Samuel Marchant wrote:
Some of the smaller 2gb  and 4gb desktops will be just fine for a Tomcat in someone's small business but may need the database with it.

Perhaps, but these days a 4GB Raspberry Pi runs $USD 75 and it's quite enough computer to run Tomcat. Meaning that a "desktop" could be dedicated solely to the database, if money is exceptionally tight. For myself, I recycle old Windows boxes.

Samuel Marchant wrote:
Tomcat itself only allows 1gb max RAM on one of its reserves on the command line the other two are smaller assignment again, so I don't see where it will get either RAM or bus and head time from for requests.

I don't know what that means, but if it relates to the memory parameters, that limit applies only to 32-bit versions of Java. Which you shouldn't be running if you have more than 4GB of RAM anyway.

Samuel Marchant wrote:
Servers don't check clients cache they send initial data and caching headers for the output information, as of proxy cache , in http 1.1 if the cache is set private the proxy will have no contact with the client data and it's controls, for a proxy to cache the data must be set public (http 1.1 cache -control header) as every government that is not USA or Russia stipulated for internet cafes.

Here you've totally lost me.

Normal practice on generated HTTP Responses that are cacheable is to include headers that have an expiration "date" on them. When a full-featured web client makes URL requests, it checks its local cache first to see if A) the URL has been previously cached and B) if the cached item has expired. Only then will the client make a network request to get a fresh copy of the expired/not-found resource.

If you have a Reverse Proxy. listening at your server's external IP/address and port, it will check its own cache memory and files and, if possible serve from them. If the reverse proxy cannot satisfy the request, it then passes the request on through to the webapp server (Tomcat).
 
Samuel Marchant
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To:  Tim holoway
"committed" is a typo error from my phone's autocomplete, including its averice removal of other text that was there.

What should been there is the server a new desktop settings are not conjoined their values and actions (have entirely different purpose) and are entirely the choice of the setup administrator and operator.
So makes it a rather euphemistic example.
 
Tim Holloway
Saloon Keeper
Posts: 23689
161
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You're not using Google Translate, are you? Because several of those words read like they were chosen without knowledge of their finer meanings or usage. That is, as though selected by someone with a translating dictionary or using a computer to translate. It reminds me of a novel* by Roger Zelazny where an alien used the term "handed a brace of roods" to mean "double-cross". Technically, a brace is two ot more roods (crosses or crucufixes), but double-cross is a slang-like reference to betrayal. So the words translate, but the meaning does not.

I'm afraid the same applies here. I haven't a clue what that previous post meant.

------
* The book in question is "Doorways in the Sand", incidentally. and I believe that Zelazny's Chronicles of Amber is slated to appear as a television series soon.
 
Samuel Marchant
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

No it isn't translation.
The phone is throwing typos.
I consider this thread sabotaged, being bloated out of substance by unneeded criticisms to obscure simple short valid statements.
Why write a Ramfile system , why produce Java, there is C C++ .
Stupid criticism of the Ramfile system it has its customising advantages
 
Tim Holloway
Saloon Keeper
Posts: 23689
161
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm sorry you feel that way, but if your phone is damaging your claims that much, then I suggest you make your case on a regular computer system where there's a keyboard that doesn't mangle your justifications into unintelligible statements.

Many things are created. Some are immediately useful, Some only find their uses after time - the laser being a classic example. Some are very useful for a time, but become less so as the world changes. Like buggy whips. And some, alas, are more useful for knowledge and experience gained by work on the project than for the final result.

I was actually hoping to see a simple spreadsheet with some timings and maybe some examples of how your system out-performs existing caching systems in concrete rather than theoretical terms. There are, as I've said, many caching products already available and in wide use, each with its strong and weak features.

That means in practical terms, a person who wants better web performance isn't going to be choosing whether or not to pick your product out of the available pile of cache solutions, but why they should consider it over the other competitors. That's especially important in the beginning, since people already have experience and familiarity with things like Squid, varnish, redis, and the caching functions of servers such as nginx. There is less work if they don't have to learn a new product and there are existing support groups with lots of accumulated knowlege to help them with their problems.

Of course, none of those product burst into the world to cheering crowds either. They got there by demonstrating a clear benefit. And that's all I'm asking to see.
 
Samuel Marchant
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If grabbing hold of the file and http commands straight from the server API for custom handling isn't a benefit then what the hell is?
Keeping it out of read/write heads on critical software such as query driven sites utilise is another I fail to see criticisms being valid, on that point, some entry level server boards that take a coffee lake have a thing called a Superdome flash drive on the board, I've heard the exact same style criticism by some disc suppliers  of SSD type equipment talking they suddenly fail, then there is the heavy usage in these cheap boards (only twice the cost you mentioned for a whole 4gb desktop) of RAID with up to six ports.
If it's required for the implementation.
Leave it to the users to decide if it suits, not deregate it.
Everything done before this in the world has been done in C C++ and that in assembly.

https://www.scribd.com/document/470554983/javax-servlet-Ramfile-Interface-and-org-apache-catalina-core-RAMfileArray
 
Saloon Keeper
Posts: 6969
164
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Samuel Marchant wrote:
Keeping it out of read/write heads on critical software such as query driven sites utilise is another


the point you seem to miss is that there are numerous ways to do this, and it's not clear that the approach of using customized server  software is better, or even as good, as other well-established approaches. you need to convince people of the benefits of your approach, which seem clear to you, but they're not clear at all when looked at from the outside, as Tim H has explained in much detail. This is your chance to do so - run with it, and people are much more likely to be interested.
 
Tim Holloway
Saloon Keeper
Posts: 23689
161
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The frustrating part is the repeated blind assertion that the read/write heads are being used to the point where it's essential to provide a new solution to avoid that. We've seen no concrete evidence that, considering how much work goes into avoiding physical I/O by the OS itself, that the read/write heads are really being used at all.

How many times have we told people in the optimization forum not to optimize based on what you "know", but to optimize based on what you measure? That's all I've ever asked for. Measurements. Because "Common sense" is just a way for the lazy to avoid thinking and it's frequently wrong.
 
Samuel Marchant
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Holloway wrote:The frustrating part is the repeated blind assertion that the read/write heads are being used to the point where it's essential to provide a new solution to avoid that. We've seen no concrete evidence that, considering how much work goes into avoiding physical I/O by the OS itself, that the read/write heads are really being used at all.

How many times have we told people in the optimization forum not to optimize based on what you "know", but to optimize based on what you measure? That's all I've ever asked for. Measurements. Because "Common sense" is just a way for the lazy to avoid thinking and it's frequently wrong.



Regardless what you have shares in, the assertion can be made it does avoid extra hardware BUS hops as much disk IO  without measurement apart you neatly downplay the fact it would be available through the server API as much custom handling of critical supply files from a business.
 
Tim Moores
Saloon Keeper
Posts: 6969
164
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Assertions are just that - assertions. Without corroborating evidence they're as likely to be false as to be true.

The part about the server API is irrelevant if there's no speedup. It doesn't fulfill a business need.
 
Samuel Marchant
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Moores wrote:Assertions are just that - assertions. Without corroborating evidence they're as likely to be false as to be true.

The part about the server API is irrelevant if there's no speedup. It doesn't fulfill a business need.



You have that wrong, it does speed it for the files if not matches other is caching scenario such as the OS, and of business needs "speak for yourself".
It is reasonably irrelevant how it is cached in RAM  except it does not do repeater hops through the hardware or interfere with disk IO of more disk intensive software
Want a piece of proof, Java cannot sell sell because of the fault it has if you were right in your statements against JVM efficiency by the mechanism it allows in the process used in the code.
What you are saying about the JVM is equivalent alike to saying a 5gig CPU with the same number of cores as a 2gig CPU has no speed and data throughput advantage over the 2gig CPU.
Stop trying to conclude by arguing a proof that at present exists neither for or against anyhow and is extremely unlikely in any favour against my code.
 
Tim Moores
Saloon Keeper
Posts: 6969
164
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Samuel Marchant wrote:a proof that at present exists neither for or against anyhow and is extremely unlikely in any favour against my code.


OK, I think that's what we have been trying to find out: there is at present no indication that the approach is yielding speedups, just a supposed likelihood that it does. It may be hard to attract users to your project on the basis of that, but good luck!
 
Tim Holloway
Saloon Keeper
Posts: 23689
161
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Samuel Marchant wrote:Want a piece of proof, Java cannot sell sell because of the fault it has if you were right in your statements against JVM efficiency by the mechanism it allows in the process used in the code.



If the instructions on using it as as nonsensical as this, then nobody is going to be able to use this.

This isn't a phone's spelling corrector at work, these words are random gibberish and make no sense whatever.

Please find someone with better English skills to help you.

And forget about attempting to define reality by brute force of "it's true because I say it's true." Someone already has that job in this country.
 
Samuel Marchant
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Holloway wrote:

If the instructions on using it as as nonsensical as this, then nobody is going to be able to use this.

This isn't a phone's spelling corrector at work, these words are random gibberish and make no sense whatever.

Please find someone with better English skills to help you.

And forget about attempting to define reality by brute force of "it's true because I say it's true." Someone already has that job in this country.



I don't find your explanations coherent, because any other grammatic construct eludes me will say I don't find the attitude in it with any clear good intent.
 
Samuel Marchant
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sept 21 2020
Just found a major bug in the code ! ! !
In fileloader() method in both classes it is incrementing or resetting the array index before the variable is set on the array ! ! !

Other class is B64 for data:image and MIME attachments in mail.
 
Samuel Marchant
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Update 23rd Sept
Reasonably complete with a few minor hiccups sorted

https://www.scribd.com/document/477020061/Modifying-Tomcat

 
Samuel Marchant
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Update 25th - should all work after compile now

Don't forget to bind the output libs to your editor so it knows you are compiling a web app with those binaries when writing jsp or servlet

New docs
And concatenated repaired
String literal conc. - I was right it works, it was syntax input, those commas are tiny
 
rubbery bacon. crispy tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
reply
    Bookmark Topic Watch Topic
  • New Topic