Delivery Status Notification (Failure)
by postmaster＠lists.jboss.org
This is an automatically generated Delivery Status Notification.
Unable to deliver message to the following recipients, because the message was forwarded more than the maximum allowed times. This could indicate a mail loop.
xlcmhsjkjuqrhvhxqls(a)technodom.kz
17 years, 11 months
[Installation, Configuration & DEPLOYMENT] - Re: OutOfMemory Error when redeploying application
by manleon
Thanks Peter and Jaikiran.
@Jaikiran. Both of your wiki links were very useful and I gained a lot.
@Peter. I referend to ur posts in following topic
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=115689
As the solution suggests I have increased the Perm Gen space by adding a parameter in run.bat to a size of 128MB.
Yes I have got the solution and now even if i redeploy no error comes even if I redeploy 2 to three times. And thanks for that.
But from the output of PrintHeapAtGC I am confused at one thing. First let me show u the output after the server is on for the first time and my application is deployed for the first time.
| {Heap before gc invocations=113:
| def new generation total 13184K, used 13034K [0x03a60000, 0x048a0000, 0x07340000)
| eden space 11776K, 100% used [0x03a60000, 0x045e0000, 0x045e0000)
| from space 1408K, 89% used [0x04740000, 0x0487abc0, 0x048a0000)
| to space 1408K, 0% used [0x045e0000, 0x045e0000, 0x04740000)
| tenured generation total 116544K, used 54035K [0x07340000, 0x0e510000, 0x23a60000)
| the space 116544K, 46% used [0x07340000, 0x0a804dc8, 0x0a804e00, 0x0e510000)
| compacting perm gen total 131072K, used 47427K [0x23a60000, 0x2ba60000, 0x2ba60000)
| the space 131072K, 36% used [0x23a60000, 0x268b0fb0, 0x268b1000, 0x2ba60000)
| No shared spaces configured.
| [GC 67070K->55756K(129728K), 0.0364396 secs]
| Heap after gc invocations=114:
| def new generation total 13184K, used 1060K [0x03a60000, 0x048a0000, 0x07340000)
| eden space 11776K, 0% used [0x03a60000, 0x03a60000, 0x045e0000)
| from space 1408K, 75% used [0x045e0000, 0x046e9008, 0x04740000)
| to space 1408K, 0% used [0x04740000, 0x04740000, 0x048a0000)
| tenured generation total 116544K, used 54696K [0x07340000, 0x0e510000, 0x23a60000)
| the space 116544K, 46% used [0x07340000, 0x0a8aa2d0, 0x0a8aa400, 0x0e510000)
| compacting perm gen total 131072K, used 47427K [0x23a60000, 0x2ba60000, 0x2ba60000)
| the space 131072K, 36% used [0x23a60000, 0x268b0fb0, 0x268b1000, 0x2ba60000)No shared spaces configured.
| }
|
Now with my application deployed perm gen space is used 36%. Fine.
Now I undeploy the application from the server while keeping it running. And after few minutes of time this is the output of GC.
| {Heap before gc invocations=199:
| def new generation total 13184K, used 12548K [0x03a60000, 0x048a0000, 0x07340000)
| eden space 11776K, 100% used [0x03a60000, 0x045e0000, 0x045e0000)
| from space 1408K, 54% used [0x04740000, 0x04801160, 0x048a0000)
| to space 1408K, 0% used [0x045e0000, 0x045e0000, 0x04740000)
| tenured generation total 116544K, used 94782K [0x07340000, 0x0e510000, 0x23a60000)
| the space 116544K, 81% used [0x07340000, 0x0cfcf8d0, 0x0cfcfa00, 0x0e510000)
| compacting perm gen total 131072K, used 70680K [0x23a60000, 0x2ba60000, 0x2ba60000)
| the space 131072K, 53% used [0x23a60000, 0x27f66110, 0x27f66200, 0x2ba60000)
| No shared spaces configured.
| [GC 107330K->95565K(129728K), 0.0289821 secs]
| Heap after gc invocations=200:
| def new generation total 13184K, used 185K [0x03a60000, 0x048a0000, 0x07340000)
| eden space 11776K, 0% used [0x03a60000, 0x03a60000, 0x045e0000)
| from space 1408K, 13% used [0x045e0000, 0x0460e548, 0x04740000)
| to space 1408K, 0% used [0x04740000, 0x04740000, 0x048a0000)
| tenured generation total 116544K, used 95380K [0x07340000, 0x0e510000, 0x23a60000)
| the space 116544K, 81% used [0x07340000, 0x0d065260, 0x0d065400, 0x0e510000)
| compacting perm gen total 131072K, used 70680K [0x23a60000, 0x2ba60000, 0x2ba60000)
| the space 131072K, 53% used [0x23a60000, 0x27f66110, 0x27f66200, 0x2ba60000)
| No shared spaces configured.
| }
|
Now here we can see perm gen space is used 53% and I have my application undeployed. Also I have not hit the server URL even once.
So here my doubt is even by increasing the perm gen space It will just increase the longevity of the server life before the error comes. But the error is suppose to come in near future.
Is my understanding correct. Or am I really perplexed by the system's internal stuff.
Please provide me guiding lines.
Thanks in Advance
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163869#4163869
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163869
17 years, 11 months
[JNDI/Naming/Network] - Re: Data Source JNDI lookup fails in a WAR
by jaikiran
anonymous wrote : 14:18:53,593 INFO [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=Data
| SourceBinding,name=TestDB' to JNDI name 'java:TestDB'
| 14:18:57,109 INFO [TomcatDeployer] deploy, ctxPath=/test, warUrl=.../deploy/test.war/
This shows that the datasource is being deployed correctly at the right time (before the war deployment).
anonymous wrote :
| 14:25:14,296 ERROR [STDERR] at org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:130)
| 14:25:14,296 ERROR [STDERR] at com.my.yoav.test.doGet(test.java:64)
This looks strange. I had not expected a spring framework related class in the JNDI lookup stacktrace. Can you post the code which does the lookup? Are there any spring classes involved in that?
The common way of looking up JNDI objects is:
Context ctx = new InitialContext();
| ctx.lookup("java:/TestDB");
This code would use the jndi.properties in the conf folder of JBoss and use the appropriate INITIAL_CONTEXT_FACTORY and other properties.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163862#4163862
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163862
17 years, 11 months
[JBoss jBPM] - Re: How to deploy a BPEL process using the APIs?
by alex.guizar＠jboss.com
I made a mistake in my last post. ProcessDeployer and DeployProcessTask only submit the process file URL. In jBPM BPEL 1.1.GA this trivial deployment mechanism was replaced with a HTTP file upload. Please look at the DeploymentTask instead, which relies the Apache HttpClient library to perform the actual upload.
protected void writeRequest(PostMethod post) throws IOException {
| // process part
| String contentType = URLConnection.getFileNameMap().getContentTypeFor(processArchive.getName());
| FilePart processPart = new FilePart("processArchive", processArchive, contentType,
| FileUtil.DEFAULT_CHARSET.name());
|
| // multipart request
| post.setRequestEntity(new MultipartRequestEntity(new Part[] { processPart }, post.getParams()));
|
| log("deploying process: " + processArchive.getName());
| }
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163861#4163861
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163861
17 years, 11 months
Delivery Notification <pollyt@uni.edu>
by Postmaster＠lists.jboss.org
This is a delivery status notification, automatically generated by MTA carney.uni.edu on Fri, 11 Jul 2008 08:20:03 -0500
Regarding recipient(s) : pollyt(a)uni.edu
Delivery status : Failed. Message could not be delivered to domain <uni.edu> .Failed while initiating the protocol. <[('pollyt(a)uni.edu', 550, '5.1.1 Recipient unknown')]>
MTA Response :550
The original message headers are included as attachment.
17 years, 11 months
