Apache Ignite: What is Ignite?

Apache Ignite(TM) In-Memory Data Fabric is a high-performance, integrated and distributed in-memory platform for computing and transacting on large-scale data sets in real-time, orders of magnitude faster than possible with traditional disk-based or flash-based technologies.



You can view Ignite as a collection of independent, well-integrated, in-memory components geared to improve performance and scalability of your application. Some of these components include:

Apache Ignite APIs

Apache Ignite has a reach set of APIs that are covered throughout the documentation. The APIs are implemented in a form of native libraries for such major languages and technologies as Java, .NET and C++ and by supporting a variety of protocols like REST, Memcached or Redis.

The documentation that is located under this domain is mostly related to Java. Refer to the following documentation sections and domains to learn more about alternative technologies and protocols you can use to connect to and work with an Apache Ignite cluster:

Fork It on GIT

How to find e-mail address source

Some times we need to find the source location of the sender of an email, or even the IP Address of the sender. This may not be a general case requirement, but even for the fun of it, or just out of curiosity, the recipient would want to search for such information.

One of our twitter followers asked us the same question on twitter

I decided to try this on one of the spam advertisers:

In the following steps you’ll learn how to find and copy an email header and paste it into the Trace Email Analyzer to get the sender’s IP address and track the source.

Would you like to track down (or trace) where an email that you received came from?

This Trace Email tool can help you do precisely that. It works by examining the header that is a part of the emails you receive to find the IP address. If you read the IP Lookup page, you’ll get a clear idea of what information an IP address can reveal.

(A header is the unseen part of every sent and received email. To learn a little bit more on headers, click here. You can see an example of a header at the end of this article.)

What email provider do you use?

To find the IP address of a received email you’re curious about, open the email and look for the header details. How you find that email’s header depends on the email program you use. Do you use Gmail or Yahoo? Hotmail or Outlook?

For example, if you’re a Gmail user, here are the steps you’d take:

  1. Open the message you want to view
  2. Click the down arrow next to the “Reply” link
  3. Select “Show Original” to open a new window with the full headers


  1. Get instructions for locating a header for your email provider here
  2. Open the email you want to trace and find its header
  3. Copy the header, then paste it into the Trace Email Analyzer below
  4. Press the “Get Source” button
  5. Scroll down below the box for the Trace Email results!

You should know that in some instances people send emails with false or “forged” headers, which are common in spam and unwanted or even malicious e-mail. Our Trace Email tool does not and cannot detect forged e-mail. That’s why that person forged the header to begin with!


source: http://whatismyipaddress.com/

When and how much to mix technologies for a project?

The main idea behind using a technology is to harness the power of code re-usability and libraries that have already been worked on and trusted to be working and functional with minimal or no issues.

The term “Technology” does not just refer to Java or C++ or JavaScript. It also refers to the frameworks that can be used to suffice some or the other requirements with minimum cost and minimal effort investment. One example can be any Application Development Framework Like Oracle ADF, Pega or Drupal, etc. The framework itself provides functionalities that are most common and also takes cares of the issues that people face while developing an application.

Any application which has to be developed from scratch needs a lot of work just to be useful enough to be used in Production environment. Basic Non-functional requirements such as MVC Architecture, Security safeguards, Application Performance, etc. are the basic and most common features of the application. In addition, Secure Login, User Registration and authentication, role mapping and similar features are also mandatory features of the application.

Most frameworks provide features such as configurable work flows, built in UI Elements, security aspects and many other features. Features such as SQL Escaping, HTML Tag Escaping and MVC Pattern architecture are generally already inbuilt to the framework. The developers can simply configure the workflows, create screens and corner out application logic and then the application is good to go.

But is that enough that we may need??

This the main question that we need to ask when trying to select technologies and try to mix them to achieve the application requirement. The Case study can be a sample B-2-B Application say Business-2-Go (B2G).

Advantage of Techs to be selected:

The B2G can be based on 3 major technology products namely an Identity Management System, an Application Development Framework, and a Content Management Service. The technologies in combination provide the architecture to harness the features out of the box.

The IDM would provide Session Maintenance, Role Mappings, Access Authentications and invalid access handling.

CMS on the other hand takes care of the static content of the application. This technology handles the application content which needs to be configurable but would be changed in very rare scenarios. The main usefulness lies in the fact that the CMS portal can be exposed to the customer admin team as well and be comfortable as the code base will not be touched by the Non Development User.

The ADF constitutes to the application flow of the B2G. All user interactions and other business logic is handled by this technology. The flexibility of the framework helps create applications quickly and more efficiently than the older technologies/frameworks such as J2EE Servlets/JSP or struts and so on.

Further technologies like JavaScript, jQuery, CSS have been used to achieve the look and feel that was decided by the client.

Disadvantages of Techs to be selected:

The disadvantages or rather limitations of the tech or the team using the tech is the one that decides whether the tech can be used or not.

The major factors can be:

  • Cost: The technology that has been perfected and supported may be in most cases be licensed. Thus incurring costs to the budget of the project. The alternative may be using Open Source technologies/frameworks. But there the problem exists of the credibility of the source, issue support and whether documentation is enough or not.
  • Resource Availability: Assuming that the cost barrier of the license has been overcome. Now the major concern is whether the resources for the technology are available or not. If not, then can existing resources be trained or can new resources can be acquired. Again the cost factor is affected in this concern.
  • Technology Limitations: Technologies have limitations in themselves also. The limitation may not be a feature that cannot be achieved, but the effort that may be involved in achieving the feature. A simple example may be a particular look and feel of a B2G. Many of the UI Elements may or may not be achievable with the selected core ADF. Or even if they are achievable, it is after a lot of R&D or with lot of hit and trials. Though this is not something that may rule out the technology itself, but may be enough to include other technologies like jQuery into the picture.
  • Interfacing efforts: While mixing technologies, spots/hooks need to be found where 1 tech may latch on to or may be placed in with the other. For example, jQuery is an Independent Tech and in the selected ADF, generally has an internal client side scripts are functioning on its own end. There may be provisions which execute scripts that achieve the UI functionalities. Similarly the CMS may not have stable out of the box connectors to code layer of the application. Thus interfaces are written to implement make this possible. This effort may also turn out to be a concern for using a tech.

An example of tech selection may be PHP. The technology PHP can also be used for creating a complete application and 99% of the same application can be achieved using PHP frameworks. In fact the cost of the tech is 0 (Open Source) and resource costing would be way lower than those of licensed application framework. But the efforts and timescale needed to achieve all the functionalities required will be humongous. Thus ruling out the tech.

Another concern that can be raised is how much the technologies can be mixed. Surely each of the frameworks will be providing some or the other comfort or a feature. Even if they are published in open source or you may have license available. Does that mean that all technologies should be mixed..??

Interfacing technologies uses effort. It also invokes limitations. An example may be the various attempts to integrate popular front-end framework like AngularJS with Oracle ADF. Oracle ADF is a mainly a Server Side Technology, maintaining all functionalities server side and providing a wide palette of features for an application. AngularJS on the other hand is a completely UI framework. It is completely Client Side Intensive Tech. Both frameworks are completely in the opposite directions. Both are unaware of the other. There are blogs showing way how to integrate both the technologies. But all can point out the issues in the integration. This is a small example, but scaling this, similar issues may be faced and thus may be counted as factors in Tech Selection.

In Conclusion, the trade-offs govern the selections of the technologies to be used in a project. Proper selections must be made in order to plan out the architecture. Improper selection may lead to issues, crashes, late deliveries or redundant costs.


Image: https://www.systrends.com/sites/default/files/banner/appdev_banner2.jpg