Heap Dump

jmap -dump:format=b,file=heap.bin 518

Mule 1.x: Spring Integration

Integrating a Spring configuration file into a Mule configuration has been the most frustrating thing in the world... well at least for me.

Mule provides documentation for using Spring with Mule 1.x in the following URL:
http://www.mulesource.org/display/MULEUSER/Using+Spring+as+a+Component+Factory

However, after following these instructions, there are a couple of things that were left undocumented for the spring application context xml to be integrated successfully. The following are these undocumented notes:

1. The Spring application context xml file should not include a XML schema definition. It should specify the Mule-specific DTD.
   
   Example Spring XML:
   
   
   <beans xmlns="http://www.springframework.org/schema/beans" xsi="http://www.w3.org/2001/XMLSchema-instance" schemalocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">
   
   ......
   </beans>
   
   In order for the Spring XML file to be read successfully by the Mule Server, the above Spring XML file must modified to use the DTD file, and not the XML Schema as follows:
   
   <!DOCTYPE beans PUBLIC "-//MuleSource //DTD mule-configuration XML V1.0//EN"
   "http://mule.mulesource.org/dtds/spring-beans.dtd">
   <beans>
   .......
   </beans>
   
   If you do not do this, the Mule server will throw the following exception and cause you frustration beyond belief (jk):
   
   nested exception is org.xml.sax.SAXParseException: : XML-20149: (Error) Element 'beans' used but not declared.
   
   
2. When specifying the <contianer-context> element, remember to define it at the appropriate place in the mule configuration xml.
   
   

   <!ELEMENT mule-configuration (description?,environment-properties?,mule-environment-properties?,container-context*,security-manager?,
   transaction-manager?,agents?,connector*,endpoint-identifiers?,transformers?,global-endpoints?,
            interceptor-stack*,model*)

   
   From the above DTD element, the container-context element should be after the mule-environment-properties element and before any connector, transformer, and model elements.
   
   If this is not the case, the Mule Server will throw the following exception:
   
   SAXParseException: : XML-20148: (Error) Invalid element 'container-context' in content of 'mule-configuration', expected elements '[connector, endpoint-identifiers, transformers, global-endpoints, interceptor-stack, model]'.
   
   It will indicate the mule-configuration DTD element that does not even contain the container-context element, which may be quite confusing.
   
   

So, it seems most of these are related to DTD and XML schema definitions.

Esper

Oracle SQL: Calculating on a Running Window

select t1me, m1n, m1n_1, m1n_2, m1n_3, m1n_4, m1n+m1n_1+m1n_2+m1n_3+m1n_4 fiveminspan from
(select
trunc(record_timestamp,'MI') t1me,
count(*),
LEAD(count(*), 0, -1) OVER (ORDER BY trunc(record_timestamp,'MI') ASC) m1n,
LEAD(count(*), 1, -1) OVER (ORDER BY trunc(record_timestamp,'MI') ASC) m1n_1,
LEAD(count(*), 2, -1) OVER (ORDER BY trunc(record_timestamp,'MI') ASC) m1n_2,
LEAD(count(*), 3, -1) OVER (ORDER BY trunc(record_timestamp,'MI') ASC) m1n_3,
LEAD(count(*), 4, -1) OVER (ORDER BY trunc(record_timestamp,'MI') ASC) m1n_4
from REP_OWNER.BAM_MEDIA_REPORT where
record_timestamp > TO_DATE('03/30/2008', 'MM/DD/YYYY') and
record_timestamp < TO_DATE('09/29/2008', 'MM/DD/YYYY')
group by trunc(record_timestamp,'MI')
order by count(*) desc)

Lesson of the Day: Data Integrity

Often, one needs to make sure that the data of one service/application is not inappropriately saved/cached in another service/application. This ensures the integrity of the data.

A single service/application may be responsible for providing a particular type of data. This data should not be cached or saved in another application. In this way, all data of this type is solely accessed from this application/service. All applications/services requesting this data would have to always retrieve it from this single service/application. Typically, however, other applications/services may reference data within this single application with an identifier or id which can be used and passed to the single service to access the actual original data. Therefore, data the actual data would not be replicated by the other services/application.

If the actual data were to be saved/cached in another application/service in order that the original service does not have to be called and thus improve performance, data integrity cannot be ensured. The data would then inadvertently be saved in two locations. If the data needs to change, one would have to update these two locations to ensure the integrity of the data.

This is a basic notion of application design.

Therefore, one needs to be careful in caching actual data that can be accessed from another service as opposed to simply saving the reference to the data which can be used for accessing the data in the originating service/application.

Database Views

Views should be created if a query is required for accessing data from multiple tables and multiple rows of multiple tables.

CORE3282: Crash occurred in function

[01/May/2008:11:05:23] fine ( 6208): Successfully initialized web application environment for virtual server [https-bamws]
[01/May/2008:11:05:35] info ( 6208): CORE3282: stdout: WebappClassLoader: Additional JARs have been added : 'hibernate-3.2.3.jar'
[01/May/2008:11:05:39] info ( 6208): WEB2798: [] ServletContext.log(): WEB3945: Scratch dir for the JSP engine is: /opt/sunone/https-mtan/ClassCache/https-bamws/default-webapp
[01/May/2008:11:05:39] info ( 6208): WEB2798: [] ServletContext.log(): WEB3947: IMPORTANT: Do not modify the generated servlets
[01/May/2008:11:05:44] catastrophe ( 6208): CORE3260: Server crash detected (signal SIGSEGV)
[01/May/2008:11:05:44] info ( 6208): CORE3262: Crash occurred in function pblock*NVPairs::dup()const from module /opt/sunone/bin/https/lib/libns-httpd40.so

Scenario:

I removed all jars from WEB-INF/lib with rm -r *, populated it with a new lib directory, restarted the server and the above error occurred. Restarting the server every time still caused this same error.

I tried to remove all references to this web app in the server.xml file, but the error still occurred.

Cause:

This could have been possibly caused by the removal of jars that while the server was still running. Perhaps, an artifact of the jar remained after subsequent restarts and would continuously cause the crash on the server.

Solution:

I removed the hibernate-3.2.3.jar from this lib directory and the web server now starts without error.