[JBoss JIRA] (WFLY-1973) Pooled Connection Factory error on server :reload
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-1973?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-1973:
------------------------------
Summary: Pooled Connection Factory error on server :reload (was: Errors on server :reload)
> Pooled Connection Factory error on server :reload
> -------------------------------------------------
>
> Key: WFLY-1973
> URL: https://issues.jboss.org/browse/WFLY-1973
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.0.0.Beta1
> Reporter: Frank Langelage
> Assignee: Jeff Mesnil
> Attachments: server.log
>
>
> Having WildFly 8.0.0.Beta1 build from current sources.
> After server is online without deployments I executed
> $JBOSS_HOME/bin/jboss-cli.sh --connect --command=":reload"
> This shows
> 22:27:45,605 ERROR [org.jboss.msc.service.fail#startFailed] MSC000001: Failed to start service jboss.messaging.default.jms.pooled-connection-factory.hornetq-ra: org.jboss.msc.service.StartException in service jboss.messaging.default.jms.pooled-connection-factory.hornetq-ra: JBAS011639: Failed to create resource adapter at org.jboss.as.messaging.jms.PooledConnectionFactoryService.start(PooledConnectionFactoryService.java:309)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.naming.context.java.jboss.DefaultJMSConnectionFactory is already registered
> at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.as.messaging.BinderServiceUtil.installAliasBinderService(BinderServiceUtil.java:72)
> at org.jboss.as.messaging.jms.PooledConnectionFactoryService.createJNDIAliases(PooledConnectionFactoryService.java:437)
> at org.jboss.as.messaging.jms.PooledConnectionFactoryService.createService(PooledConnectionFactoryService.java:423)
> at org.jboss.as.messaging.jms.PooledConnectionFactoryService.start(PooledConnectionFactoryService.java:306)
> ... 5 more
> See attached server.log.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (WFLY-1385) Override default page-size-bytes in messaging subsystem configuration
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1385?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1385:
-----------------------------------------------
Miroslav Novak <mnovak(a)redhat.com> made a comment on [bug 920980|https://bugzilla.redhat.com/show_bug.cgi?id=920980]
I've set the correct status per doc: https://docspace.corp.redhat.com/docs/DOC-154066
It's good to check to it.
> Override default page-size-bytes in messaging subsystem configuration
> ---------------------------------------------------------------------
>
> Key: WFLY-1385
> URL: https://issues.jboss.org/browse/WFLY-1385
> Project: WildFly
> Issue Type: Enhancement
> Components: JMS
> Affects Versions: 8.0.0.Alpha1
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Minor
> Fix For: 8.0.0.Alpha2
>
>
> When HornetQ address-full-policy is switched from BLOCK to PAGE, the following exception is thrown during shutdown.
> {noformat}
> Exception:
> 09:48:05,247 WARN [org.hornetq.core.server] (MSC service thread 1-3) HQ222160: unable to send notification when broadcast group is stopped: java.lang.IllegalStateException: pageSize for address hornetq.notifications >= maxSize. Normally pageSize should be significantly smaller than maxSize, ms: 10485760 ps 10485760
> at org.hornetq.core.paging.impl.PagingStoreImpl.<init>(PagingStoreImpl.java:147) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
> at org.hornetq.core.paging.impl.PagingStoreFactoryNIO.newStore(PagingStoreFactoryNIO.java:98) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
> at org.hornetq.core.paging.impl.PagingManagerImpl.newStore(PagingManagerImpl.java:250) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
> {noformat}
> The standalone-full.xml configuration overrides the default address-setting's max-size-bytes (defaults to -1) to set it at 10 MiB.
> However, if the admin changes the address-full-policy from BLOCK to PAGE, it will conflict with the default value for page-size-bytes which is also 10MiB.
> To make the overridden standalone-full.xml more consistent, we can override page-size-bytes and set it to 2MiB (2097152 bytes). This change has no effect when the address-full-policy remains at BLOCK. When it is changed to PAGE, the resulting configuration will be coherent and there will be no exception thrown
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (WFLY-1385) Override default page-size-bytes in messaging subsystem configuration
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1385?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1385:
-----------------------------------------------
Miroslav Novak <mnovak(a)redhat.com> changed the Status of [bug 920980|https://bugzilla.redhat.com/show_bug.cgi?id=920980] from NEW to MODIFIED
> Override default page-size-bytes in messaging subsystem configuration
> ---------------------------------------------------------------------
>
> Key: WFLY-1385
> URL: https://issues.jboss.org/browse/WFLY-1385
> Project: WildFly
> Issue Type: Enhancement
> Components: JMS
> Affects Versions: 8.0.0.Alpha1
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Minor
> Fix For: 8.0.0.Alpha2
>
>
> When HornetQ address-full-policy is switched from BLOCK to PAGE, the following exception is thrown during shutdown.
> {noformat}
> Exception:
> 09:48:05,247 WARN [org.hornetq.core.server] (MSC service thread 1-3) HQ222160: unable to send notification when broadcast group is stopped: java.lang.IllegalStateException: pageSize for address hornetq.notifications >= maxSize. Normally pageSize should be significantly smaller than maxSize, ms: 10485760 ps 10485760
> at org.hornetq.core.paging.impl.PagingStoreImpl.<init>(PagingStoreImpl.java:147) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
> at org.hornetq.core.paging.impl.PagingStoreFactoryNIO.newStore(PagingStoreFactoryNIO.java:98) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
> at org.hornetq.core.paging.impl.PagingManagerImpl.newStore(PagingManagerImpl.java:250) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
> {noformat}
> The standalone-full.xml configuration overrides the default address-setting's max-size-bytes (defaults to -1) to set it at 10 MiB.
> However, if the admin changes the address-full-policy from BLOCK to PAGE, it will conflict with the default value for page-size-bytes which is also 10MiB.
> To make the overridden standalone-full.xml more consistent, we can override page-size-bytes and set it to 2MiB (2097152 bytes). This change has no effect when the address-full-policy remains at BLOCK. When it is changed to PAGE, the resulting configuration will be coherent and there will be no exception thrown
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (JBVFS-185) Switch to 'mkdirs'
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/JBVFS-185?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar resolved JBVFS-185.
-------------------------------
Fix Version/s: 3.2.0.Beta2
Resolution: Done
> Switch to 'mkdirs'
> -------------------
>
> Key: JBVFS-185
> URL: https://issues.jboss.org/browse/JBVFS-185
> Project: JBoss VFS
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Bartosz Baranowski
> Assignee: Bartosz Baranowski
> Fix For: 3.2.0.Beta2
>
>
> TempFileProvider has:
> {code}
> static {
> String configTmpDir = System.getProperty(JBOSS_TMP_DIR_PROPERTY);
> if (configTmpDir == null)
> configTmpDir = System.getProperty(JVM_TMP_DIR_PROPERTY);
> try {
> TMP_ROOT = new File(configTmpDir, "vfs");
> TMP_ROOT.mkdirs();
> }
> catch (Exception e) {
> throw new RuntimeException("Can't set up temp file provider", e);
> }
> }
> {code}
> This does its job fine when VM starts, but if something removes the directory, ie. as part of cleanup, provider stops, since createTempDir:
> {code}
> private static File createTempDir(String prefix, String suffix, File root) throws IOException {
> for (int i = 0; i < RETRIES; i++) {
> final File f = new File(root, createTempName(prefix, suffix));
> if (f.mkdir())
> return f;
> }
> throw new IOException(
> String.format("Could not create directory for root '%s' (prefix '%s', suffix '%s') after %d attempts",
> root,
> prefix,
> suffix,
> RETRIES));
> }
> {code}
> So either the static init is removed and performed for each provider( in constructor or better, in some kind of init() meethod ) or createTempDir calls File.mkdirs()
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (WFLY-1974) @Resource ManagedExecutorService produces a null field
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-1974?page=com.atlassian.jira.plugin.... ]
jaikiran pai commented on WFLY-1974:
------------------------------------
Eduardo, just a FYI - take a look at WeldResourceInjectionServices which is where the @Resource injection in CDI beans is done.
> @Resource ManagedExecutorService produces a null field
> ------------------------------------------------------
>
> Key: WFLY-1974
> URL: https://issues.jboss.org/browse/WFLY-1974
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.0.0.Alpha4
> Reporter: Juergen Zimmermann
> Assignee: Eduardo Martins
>
> I compiled the latest WildFly master and tried:
> {code}
> @Resource
> private ManagedExecutorService managedExecutorService
> {code}
> However, the injected field managedExecutorService is null. This issue is gone when I use:
> {code}
> @Resource(mappedName = "java:comp/DefaultManagedExecutorService")
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (DROOLS-167) Inaccurate comparison because of String to Double coercion
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-167?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-167:
------------------------------------------------
Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 974364|https://bugzilla.redhat.com/show_bug.cgi?id=974364] from ON_QA to VERIFIED
> Inaccurate comparison because of String to Double coercion
> ----------------------------------------------------------
>
> Key: DROOLS-167
> URL: https://issues.jboss.org/browse/DROOLS-167
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.Beta3
> Reporter: Toshiya Kobayashi
> Assignee: Mario Fusco
> Fix For: 5.5.1.Final, 6.0.0.Beta4
>
>
> If you compare String fields which consist of many digits, it may be wrongly evaluated due to String to Double coercion and Double's inaccuracy.
> The following test doesn't fire the rule.
> {code:java}
> import org.drools.compiler.Person;
> rule R1
> when
> $p : Person( name < "90201304122000000000000017" )
> then
> end
> {code}
> {code:java}
> ksession.insert( new Person( "90201304122000000000000015", 38 ) );
> {code}
> In Drools 6.0.0.beta3, the coercion is done by org.mvel2.math.MathProcessor
> {code:java}
> public strictfp class MathProcessor {
> ...
> private static Object _doOperations(int type1, Object val1, int operation, int type2, Object val2) {
> if (operation < 20) {
> if (((type1 > 49 || operation == EQUAL || operation == NEQUAL) && type1 == type2) ||
> (isIntegerType(type1) && isIntegerType(type2) && operation >= BW_AND && operation <= BW_NOT)) {
> return doOperationsSameType(type1, val1, operation, val2);
> }
> else if ((type1 > 99 && (type2 > 99))
> || (operation != 0 && isNumber(val1) && isNumber(val2))) {
> return doPrimWrapperArithmetic(getNumber(val1, type1),
> operation,
> getNumber(val2, type2), true, box(type2) > box(type1) ? box(type2) : box(type1));
> }
> ...
> private static Double getNumber(Object in, int type) {
> if (in == null)
> return 0d;
> switch (type) {
> ...
> case DataTypes.STRING:
> return Double.parseDouble((String) in);
> ...
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (DROOLS-167) Inaccurate comparison because of String to Double coercion
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-167?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-167:
------------------------------------------------
Marek Winkler <mwinkler(a)redhat.com> made a comment on [bug 974364|https://bugzilla.redhat.com/show_bug.cgi?id=974364]
Verified on BRMS 6.0.0-ER2.
> Inaccurate comparison because of String to Double coercion
> ----------------------------------------------------------
>
> Key: DROOLS-167
> URL: https://issues.jboss.org/browse/DROOLS-167
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.Beta3
> Reporter: Toshiya Kobayashi
> Assignee: Mario Fusco
> Fix For: 5.5.1.Final, 6.0.0.Beta4
>
>
> If you compare String fields which consist of many digits, it may be wrongly evaluated due to String to Double coercion and Double's inaccuracy.
> The following test doesn't fire the rule.
> {code:java}
> import org.drools.compiler.Person;
> rule R1
> when
> $p : Person( name < "90201304122000000000000017" )
> then
> end
> {code}
> {code:java}
> ksession.insert( new Person( "90201304122000000000000015", 38 ) );
> {code}
> In Drools 6.0.0.beta3, the coercion is done by org.mvel2.math.MathProcessor
> {code:java}
> public strictfp class MathProcessor {
> ...
> private static Object _doOperations(int type1, Object val1, int operation, int type2, Object val2) {
> if (operation < 20) {
> if (((type1 > 49 || operation == EQUAL || operation == NEQUAL) && type1 == type2) ||
> (isIntegerType(type1) && isIntegerType(type2) && operation >= BW_AND && operation <= BW_NOT)) {
> return doOperationsSameType(type1, val1, operation, val2);
> }
> else if ((type1 > 99 && (type2 > 99))
> || (operation != 0 && isNumber(val1) && isNumber(val2))) {
> return doPrimWrapperArithmetic(getNumber(val1, type1),
> operation,
> getNumber(val2, type2), true, box(type2) > box(type1) ? box(type2) : box(type1));
> }
> ...
> private static Double getNumber(Object in, int type) {
> if (in == null)
> return 0d;
> switch (type) {
> ...
> case DataTypes.STRING:
> return Double.parseDouble((String) in);
> ...
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (WFLY-1419) Overrides REST Response Object on Status 404
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1419?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1419:
-----------------------------------------------
Weinan Li <weli(a)redhat.com> made a comment on [bug 968572|https://bugzilla.redhat.com/show_bug.cgi?id=968572]
Verified that this bug is not fixed in jboss-as-7.3.0-internal-SNAPSHOT (EAP 6.2.0)
Verified that this bug is fixed in wildfly-8.0.0.Beta1-SNAPSHOT
> Overrides REST Response Object on Status 404
> --------------------------------------------
>
> Key: WFLY-1419
> URL: https://issues.jboss.org/browse/WFLY-1419
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Alpha1
> Environment: JBoss AS 7.1.1, JBoss EAP 6.1.0, WildFly 8.0.0.Alpha1
> Linux, Java 1.7
> Reporter: Aslak Knutsen
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Alpha2
>
>
> *Given*:
> {code:title=JAX-RS Resource Code}
> @Path("/conference")
> public class ConferenceResource implements Resource {
> private static final String BASE_MEDIA_TYPE = "application/vnd.ced+xml";
> private static final String CONFERENCE_MEDIA_TYPE = BASE_MEDIA_TYPE + ";type=conference";
> private static final String SESSION_MEDIA_TYPE = BASE_MEDIA_TYPE + ";type=session";
> ...
> @GET
> @Path("/{id}")
> @Produces("application/vnd.ced+xml")
> public Response get(@PathParam("id") String id) {
> Conference conference = repository.get(id);
> if(conference == null) {
> return Response.status(Status.NOT_FOUND).type(CONFERENCE_MEDIA_TYPE).build();
> }
> return Response.ok(
> new ConferenceRepresentation(conference, uriInfo.getAbsolutePathBuilder()))
> .type(CONFERENCE_MEDIA_TYPE).build();
> }
> ...
> }
> {code}
> *Then*:
> The Body and MediaType is overwritten by the WebContainer and standard text/html Error Page is returned.
> {code:title=Wire Log}
> DEBUG [org.apache.http.wire] >> "GET /c5b53d1f-e6fd-40a2-8656-2e36e7e92997/api/conference/d4c6bdb2-51a0-44f8-99bc-75a18ee76228 HTTP/1.1[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Accept: application/vnd.ced+xml;type=conference[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Host: 127.0.0.1:8080[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Connection: Keep-Alive[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Accept-Encoding: gzip,deflate[\r][\n]"
> DEBUG [org.apache.http.wire] >> "[\r][\n]"
> DEBUG [org.apache.http.wire] << "HTTP/1.1 200 OK[\r][\n]"
> DEBUG [org.apache.http.wire] << "Server: Apache-Coyote/1.1[\r][\n]"
> DEBUG [org.apache.http.wire] << "Content-Type: application/vnd.ced+xml;type=conference[\r][\n]"
> DEBUG [org.apache.http.wire] << "Content-Length: 422[\r][\n]"
> DEBUG [org.apache.http.wire] << "Date: Wed, 29 May 2013 02:54:22 GMT[\r][\n]"
> DEBUG [org.apache.http.wire] << "[\r][\n]"
> DEBUG [org.apache.http.wire] << "<?xml version="1.0" encoding="UTF-8" standalone="yes"?><ns3:conference xmlns:ns2="urn:ced:link" xmlns:ns3="urn:ced:conference"><ns2:link href="http://127.0.0.1:8080/c5b53d1f-e6fd-40a2-8656-2e36e7e92997/api/conference..." rel="session"/><end>2013-05-29T04:54:22.213+02:00</end><name>Test</name><start>2013-05-29T04:54:22.213+02:00</start><tagLine>Tagline</tagLine></ns3:conference>"
> DEBUG [org.apache.http.wire] >> "DELETE /c5b53d1f-e6fd-40a2-8656-2e36e7e92997/api/conference/d4c6bdb2-51a0-44f8-99bc-75a18ee76228 HTTP/1.1[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Accept: */*[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Content-Length: 0[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Host: 127.0.0.1:8080[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Connection: Keep-Alive[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Accept-Encoding: gzip,deflate[\r][\n]"
> DEBUG [org.apache.http.wire] >> "[\r][\n]"
> DEBUG [org.apache.http.wire] << "HTTP/1.1 204 No Content[\r][\n]"
> DEBUG [org.apache.http.wire] << "Server: Apache-Coyote/1.1[\r][\n]"
> DEBUG [org.apache.http.wire] << "Date: Wed, 29 May 2013 02:55:44 GMT[\r][\n]"
> DEBUG [org.apache.http.wire] << "[\r][\n]"
> DEBUG [org.apache.http.wire] >> "GET /c5b53d1f-e6fd-40a2-8656-2e36e7e92997/api/conference/d4c6bdb2-51a0-44f8-99bc-75a18ee76228 HTTP/1.1[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Accept: application/vnd.ced+xml;type=conference[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Host: 127.0.0.1:8080[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Connection: Keep-Alive[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Accept-Encoding: gzip,deflate[\r][\n]"
> DEBUG [org.apache.http.wire] >> "[\r][\n]"
> DEBUG [org.apache.http.wire] << "HTTP/1.1 404 Not Found[\r][\n]"
> DEBUG [org.apache.http.wire] << "Server: Apache-Coyote/1.1[\r][\n]"
> DEBUG [org.apache.http.wire] << "Content-Type: text/html;charset=utf-8[\r][\n]"
> DEBUG [org.apache.http.wire] << "Content-Length: 956[\r][\n]"
> DEBUG [org.apache.http.wire] << "Date: Wed, 29 May 2013 02:55:45 GMT[\r][\n]"
> DEBUG [org.apache.http.wire] << "[\r][\n]"
> DEBUG [org.apache.http.wire] << "<html><head><title>JBoss Web/7.0.13.Final - Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 404 - </h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>The requested resource () is not available.</u></p><HR size="1" noshade="noshade"><h3>JBoss Web/7.0.13.Final</h3></body></htm!
l>"
> HTTP/1.1 404 Not Found
> Server=Apache-Coyote/1.1
> Content-Type=text/html;charset=utf-8
> Content-Length=956
> Date=Wed, 29 May 2013 02:55:45 GMT
> <html xmlns="http://www.w3.org/1999/xhtml">
> <head>
> <title>
> JBoss Web/7.0.13.Final - Error report
> </title>
> <style>
> <!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}-->
> </style>
> </head>
> <body>
> <h1>
> HTTP Status 404 -
> </h1>
> <hr noshade="noshade" size="1"/>
> <p>
> <b>
> type
> </b>
> Status report
> </p>
> <p>
> <b>
> message
> </b>
> <u/>
> </p>
> <p>
> <b>
> description
> </b>
> <u>
> The requested resource () is not available.
> </u>
> </p>
> <hr noshade="noshade" size="1"/>
> <h3>
> JBoss Web/7.0.13.Final
> </h3>
> </body>
> </html>
> {code}
> *Expected*: Return the JAX-RS Response Object as defined by the JAX-RS Service.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (DROOLS-208) Build 5.6.0-SNAPSHOT on jenkins and prepare for 5.6.0.Final release
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-208?page=com.atlassian.jira.plugin... ]
Michael Biarnes Kiefer commented on DROOLS-208:
-----------------------------------------------
Jenkins View Drools 5.6.x, jBPM 5.5.x created.
> Build 5.6.0-SNAPSHOT on jenkins and prepare for 5.6.0.Final release
> -------------------------------------------------------------------
>
> Key: DROOLS-208
> URL: https://issues.jboss.org/browse/DROOLS-208
> Project: Drools
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Davide Sottara
> Assignee: Michael Biarnes Kiefer
>
> Requirements:
> 1) All repositories in the 5.6.x repository-list need to be branched from 5.5.x.
> https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/5.6.x/scrip...
> Note: the repository list is far less than master (so you can safely ignore uberfire etc).
> Warning 1: some repo's are already branched! Do not rebranch these: droolsjbpm-build-bootstrap, droolsjbpm-knowledge, drools
> Warning 2: You need to branch from 5.5.x (NOT master!) to this new branch 5.6.x
> Warning 3: jbpm uses different version numbering. You need to branch from jbpm 5.4.x to 5.5.x (NOT 5.6.x). All other repo's use the normal version.
> 2) All the 5.6.x branches (and 5.5.x for jbpm)'s versions need to change from 5.5.1-SNAPSHOT to 5.6.0-SNAPSHOT (and from 5.4.0-SNAPSHOT to 5.5.0-SNAPSHOT for jbpm).
> Note: droolsjbpm-tools's will need changes from 5.5.1.qualifier to 5.6.0.qualifier
> 3) Create a new jenkins view for "drools 5.6.x and jbpm 5.5.x"
> 4) Clone the 5.5.x jobs for all these repo's as 5.6.x jobs.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (JBREM-1324) Always hit OutOfMemoryError If I try to invoke ejb method with large object as its parameter at the marshlling step
by licheng cheng (JIRA)
[ https://issues.jboss.org/browse/JBREM-1324?page=com.atlassian.jira.plugin... ]
licheng cheng updated JBREM-1324:
---------------------------------
Attachment: SerializableInputStream.java
> Always hit OutOfMemoryError If I try to invoke ejb method with large object as its parameter at the marshlling step
> -------------------------------------------------------------------------------------------------------------------
>
> Key: JBREM-1324
> URL: https://issues.jboss.org/browse/JBREM-1324
> Project: JBoss Remoting
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: marshall
> Affects Versions: 2.2.2.SP10
> Environment: WindowsXP + jdk1.6
> Reporter: licheng cheng
> Fix For: 2.2.2.SP10
>
> Attachments: SerializableInputStream.java
>
>
> In our stateless EJB, there is one API defined as below.
> public void modelSave(SerializableInputStream model) throws java.rmi.RemoteException;
> The SerializableInputStream is defined as below and its whole definition is attached. The intent of defining such class is that sometimes we need to pass through large object (its content may be more than 300M) as parameter to remote ejb, while the -Xmx of the JVM is only 512M by default. With such serializable inputstream, expect JBoss not to load the whole object into JVM before invoking ejb method to avoid the OutOfMemoryError issue.
> public class SerializableInputStream extends InputStream implements Serializable {
> private InputStream stream;
> ....
> //---------------------------< Serializable >-------------------------------
> private void writeObject(ObjectOutputStream out)
> throws IOException {
> byte[] buffer = new byte[4096];
> int bytes;
> while ((bytes = stream.read(buffer)) >= 0) {
> // Write a segment of the input stream
> if (bytes > 0) {
> // just to ensure that no 0 is written
> out.writeInt(bytes);
> out.write(buffer, 0, bytes);
> }
> }
> // Write the end of stream marker
> out.writeInt(0);
> // close stream
> stream.close();
> }
> private void readObject(ObjectInputStream in)
> throws IOException {
> final File file = File.createTempFile("serializable-stream", "bin");
> OutputStream out = new FileOutputStream(file);
> byte[] buffer = new byte[4096];
> for (int bytes = in.readInt(); bytes > 0; bytes = in.readInt()) {
> if (buffer.length < bytes) {
> buffer = new byte[bytes];
> }
> in.readFully(buffer, 0, bytes);
> out.write(buffer, 0, bytes);
> }
> out.close();
> stream = new FileInputStream(file) {
> private boolean closed = false;
> public void close() throws IOException {
> super.close();
> closed = true;
> file.delete();
> }
> ...
> };
> }
> }
> But from the test result, I can that JBoss marshaller first read its content (the serializable inputstream) into a byte array, which means the big object is loaded into memory. With our default JVM setting, we always hit OOM issue as below
> 2013-08-07 14:30:21,001 ERROR [STDERR] Caused by: java.lang.Exception: java.lang.OutOfMemoryError: Java heap space
> 2013-08-07 14:30:21,001 ERROR [STDERR] at org.jboss.invocation.unified.interfaces.UnifiedInvokerProxy.invoke(UnifiedInvokerProxy.java:222)
> 2013-08-07 14:30:21,001 ERROR [STDERR] at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:112)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100)
> 2013-08-07 14:30:21,016 ERROR [STDERR] ... 39 more
> 2013-08-07 14:30:21,016 ERROR [STDERR] Caused by: java.lang.OutOfMemoryError: Java heap space
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.util.Arrays.copyOf(Arrays.java:2786)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ByteArrayOutputStream.toByteArray(ByteArrayOutputStream.java:133)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.MarshalledValue.<init>(MarshalledValue.java:72)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.MarshalledValueEX.<init>(MarshalledValueEX.java:47)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.unified.interfaces.JavaSerializationManager.createdMarshalledValue(JavaSerializationManager.java:105)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.MarshalledInvocation.createMarshalledValue(MarshalledInvocation.java:628)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.MarshalledInvocation.writeExternal(MarshalledInvocation.java:570)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1429)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1398)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObjectVersion2_2(JavaSerializationManager.java:119)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObject(JavaSerializationManager.java:94)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.marshal.serializable.SerializableMarshaller.write(SerializableMarshaller.java:120)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.unified.marshall.InvocationMarshaller.write(InvocationMarshaller.java:75)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedWrite(MicroSocketClientInvoker.java:969)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:606)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.Client.invoke(Client.java:1634)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.Client.invoke(Client.java:548)
> Although passing big object with Remote ejb call is not a common use case, but I think it will be better if JBoss could consider such case.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months