alex russo

Thanks for the reply, Jaikiran
From the logs i am guessing its the EJB timerService, its JBOSS 4.0. I still have not gained access to the source code. Will post it as soon as i get that.
in mean time i am trying to see if there is any way to see how the list of timeServices running in a single instance of java

Hello All,

I have gone thru some of the older posts around this topic and I could not real find what I was looking for. I have been working with JBOSS from quite recent time and I find this J2EE container is really cool and the level of features it offers are extensive and I am having hard time understanding them but anyways I want to still explore and learn these features.

So here is my issue: I have a server in production that runs on jboss and we ran into an issue in it the other day. The application that runs in this container is not developed by me and I am still trying to get my hand on its source code,
We had our jboss go into a hung state and required it to be recycled, but none of us in the current team knew that there was something called timerService being invoked at the time of application start up, so for some reason when we shut the process down this timerService was not getting killed/stopped.
Looks like we use this service to invoke certain scripts that are used to load data, now what was happening was that as we kept bouncing the jboss , timer service started adding up lets say we bounced jboss 4 times then we had 4 timer-services running that were invoking the scripts 4 times there by creating duplicates while trying to load data.

We ended recycling the entire host, which I know was the most weird thing and that kind of fixed the issue - probably it just killed all process running on the host and gave us a clean slate to start.

My question now: is there a way to see/list the number of timerServices running in a particular java instance, using something like twiddle or some command at CLI ?
and can we grep on the process id of the timerService in any way ?

I am still exploring the timerService in jboss and if my question seems naive or foolish, please pardon me.

Looking forward to here from some ranchers who can help me understand this in a simple way.

Thanks,

Alex

Hello All,

I am new to web services and trying to wrap my head around these two types.
I understand that SOAP is protocol based where as REST is an architectural style. SOAp uses XML for its envelope and REST can use XML and JSON's

My confusion/ gray area:

like in SOAP, we can view all the available web methods and there required parameters (to be passed) that are available using the ?WSDL (putting it at the end of the web service URL ). is there a similar way for REST web services.

if i want to see all the web services methods available under a service URL for RESTFUL services what should i be doing ?

another question: I was able to test the some of the web-services in soap using SoapUI however if i need to verify or test RestFul web-services what tool am i suppose to be using ?

any help in making this easier for me to understand is highly appreciated.

Format 1 , even thou when I give Service_name it interprets it as SID and the possible reason could be the usage of ':'

Format 2: when I am trying to do '/'
jdbc: oracle:thin:@//<host>:<port>/<service_name>
for some reason it still thinks it as SID and not Service_name.
it requires explicitly to provide the description, host, connect data (format) for it to consider it as Service_Name.

Any idea why ?


Some online link that I cam across that explains the meaning of ':' and '/'
http://www.razorsql.com/articles/oracle_jdbc_connect.html

Can some one please explain me the difference between the following two ways of forming a connection URL:

1)
String url_connection = null;
url_connection = "jdbc: oracle:thin:@" + context.Oracle_Server + ":"+ context.Oracle_Port + ":" + context.Oracle_ServiceName;

aganist

2)
String url_connection = null;
url_connection = "jdbc: oracle:thin:@(description=(address=(protocol=tcp)(host="+ context.Oracle_Server+ ")(port="+ context.Oracle_Port+ "))(connect_data=(service_name="+ context.Oracle_ServiceName + ")))";


and how is 2 different than jdbc: oracle:thin:@//<host>:<port>/<service_name>

thanks in advance for helping me with this.

Jeff Verdegan wrote:GC approaches and implementations change from version to version as improvements are made, so it's not surprising that the logging also changes to reflect that.

thanks for your prompt response jeff, but let me give you my example:

I have 2 environments running in glassFish a Staging and Prod, exact version of java

In staging the gc.log denotes the oldgen as "tenured generation"
In prod the gc.log denotes the oldGen as "ParOldGen"

the jvm-options i am using is below and its same in both environments. So trying to understand what is causing the difference -any dependency on the OS - i don't think so


<jvm-options>-Dcom.sun.enterprise.server.logging.max_history_files=15</jvm-options>
<jvm-options>-Xloggc:/a01/apps/xxx/glassfish/domains/domain1/logs/gc.log</jvm-options>
<jvm-options>-XX:+PrintHeapAtGC</jvm-options>
<jvm-options>-XX:+PrintTenuringDistribution</jvm-options>
<jvm-options>-XX:+PrintGCTimeStamps</jvm-options>
<jvm-options>-Dlog4j.configuration=file:///${com.sun.aas.instanceRoot}/config/log4j.properties</jvm-options>
<jvm-options>-XX:MaxPermSize=512m</jvm-options>
<jvm-options>-client</jvm-options>
<jvm-options>-Djava.endorsed.dirs=${com.sun.aas.installRoot}/lib/endorsed</jvm-options>
<jvm-options>-Djava.security.policy=${com.sun.aas.instanceRoot}/config/server.policy</jvm-options>
<jvm-options>-Djava.security.auth.login.config=${com.sun.aas.instanceRoot}/config/login.conf</jvm-options>
<jvm-options>-Dsun.rmi.dgc.server.gcInterval=3600000</jvm-options>
<jvm-options>-Dsun.rmi.dgc.client.gcInterval=3600000</jvm-options>
<jvm-options>-Xmx2048m</jvm-options>
<jvm-options>-Xms2048m</jvm-options>
<jvm-options>-Djavax.net.ssl.keyStore=${com.sun.aas.instanceRoot}/config/keystore.jks</jvm-options>
<jvm-options>-Djavax.net.ssl.trustStore=${com.sun.aas.instanceRoot}/config/cacerts.jks</jvm-options>
<jvm-options>-Djava.ext.dirs=${com.sun.aas.javaRoot}/lib/ext${path.separator}${com.sun.aas.javaRoot}/jre/lib/ext${path.separator}${com.sun.aas.instanceRoot}/lib/ext${path.separator}${com.sun.aas.derbyRoot}/lib</jvm-options>
<jvm-options>-Djdbc.drivers=org.apache.derby.jdbc.ClientDriver</jvm-options>
<jvm-options>-Djavax.management.builder.initial=com.sun.enterprise.admin.server.core.jmx.AppServerMBeanServerBuilder</jvm-options>
<jvm-options>-Dcom.sun.enterprise.config.config_environment_factory_class=com.sun.enterprise.config.serverbeans.AppserverConfigEnvironmentFactory</jvm-options>
<jvm-options>-Dcom.sun.enterprise.taglibs=appserv-jstl.jar,jsf-impl.jar</jvm-options>
<jvm-options>-Dcom.sun.enterprise.taglisteners=jsf-impl.jar</jvm-options>
<jvm-options>-XX:NewRatio=2</jvm-options>

I apologize if this question does not belong to this thread, please let me know and I will post it to the right thread.

Question: Why would the GC.LOG write differently from one server to another.
can some one explain why some jvm denote "PSYoungGen" as "new generation" and then "PSOldGen" as "tenured generation".

also the in jdk1.7.0_11 why would it denote "PSOldgen" as "ParOldGen"

I do not have the parameter in my config.xml : XX:+UseParallelGC , the reason I am quoting this is

From link: http://www.oracle.com/technetwork/java/javase/7u4-relnotes-1575007.html
Parallel Old GC (-XX:+UseParallelOldGC) is now enabled by default whenever -XX:+UseParallelGC is enabled. To revert to the previous default behavior, use the option -XX:-UseParallelOldGC on the java command line.

what is the preferred garbage collection in jdk1.7 when I don't denote "<jvm-options>-client</jvm-options>" or "<jvm-options>-server</jvm-options>"

any suggestion is highly appreciated.

Hello ,

Can some one explain me in simple terms what is "java.net.SocketTimeoutException: Read timed out" . I have searched in google and I ran into so many descriptions that I am confused now. If some one can explain me in simple terms that would be of great help.

Note: If I have created a thread in error under wrong tree structure please apologize me and move this post to appropriate location.

thanks

Alex

Thanks Tim

Thanks for the response Tim, I really appreciate taking time out.
Agreed I have to move to Tomcat 6 but I have to live with 5.5 currently since all our environments are working on this, migration is scheduled.

But here is the thing that confuses me, the Trail 1 scenario was set up on a 32-bit machine and it had always worked successfully, never had issue at least for the last 3 years it has been running the JVM knew which class to be invoked but recently we have undergone an infrastructure migration and we moved up to 64 bit servers with "Red Hat Enterprise Linux Server release 5.3 (Tikanga)' earlier we were on 32bit we were on Redhat 4.

We cam e across this issue only after migration, but note all other variables like the tomcat version, JDK , Apache all remained same just changed from 32 bit Redhat 4 to 64 bit Redhat5.3

Even if the loader is using "hashmap" is should have been able to locate the expected class with Trail 2.

Thanks once again.

-alex

Hello all,

I am a java newbie and need your help in understanding the common loader in tomcat. Please pardon me if I have created a duplicate topic/thread, I am new to the community.

Here is my issue:

I have class called PortletTitelComparator that is present in two jar's(ext-service.jar and portal-service.jar), the first jar((portal-service.jar) has method with 2 parameters and the other (ext-service.jar) has it with 3 parameters. I have made both these jar's available under tomcat/common/lib/ext/

my common loader in tomcat/conf/catalina.properties is defined as below:
Trail 1)common.loader=${catalina.home}/common/classes,${catalina.home}/common/i18n/*.jar,${catalina.home}/common/endorsed/*.jar,${catalina.home}/common/lib/*.jar,${catalina.home}/common/lib/ext/*.jar (or)
Trail2)common.loader=${catalina.home}/common/classes,${catalina.home}/common/i18n/*.jar,${catalina.home}/common/endorsed/*.jar,${catalina.home}/common/lib/*.jar,${catalina.home}/common/lib/ext/*.jar,${catalina.home}/common/lib/ext/ext-service.jar

I run into issue when one of my jsp that uses the ext-service.jar (the method defined here with3 parameters) try to compile , i see the following error, even though the jar is in my common loader path. There is a difficulty for the container to know which one has to be picked up. For some reason it never goes to the actual jar that has this class.

The constructor PortletTitleComparator(ServletContext, Locale, Hashtable) is undefined

But when I tweak my common loader as below:

Success 1) common.loader=${catalina.home}/common/classes,${catalina.home}/common/lib/ext/ext-service.jar,${catalina.home}/common/i18n/*.jar,${catalina.home}/common/endorsed/*.jar,${catalina.home}/common/lib/*.jar,${catalina.home}/common/lib/ext/*.jar

things start working as expected and the jsp gets compiled. The container can now distinguish the difference between both classes.

All that was done is to have the jar mentioned out explicitly in the common loader path before ${catalina.home}/common/lib/*

I am a bit confused here and would like to know what is happening and how does a tomcat class loader behaves and on what criteria does it load its classes when 2 jars have a similar class that exhibit method overloading. Even when i had the specific jar written (see trail-2 above) at the end of the common load path it seemed it did get picked correctly.

I would be happy if some one can explain what exactly is going on here.

Thanks in advance for any one who can spare a bit of there time and explain.

alex

I have gone thru:http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html {but did not find the answer that i am looking for } the reason i am looking at tomcat 5.5 is I am working on tomcat 5.5.