[JBoss JIRA] Created: (JBMESSAGING-629) Unneccessary puts and gets in message store
by Tim Fox (JIRA)
Unneccessary puts and gets in message store
-------------------------------------------
Key: JBMESSAGING-629
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-629
Project: JBoss Messaging
Issue Type: Task
Affects Versions: 1.0.1.GA, 1.2.0.Alpha1
Reporter: Tim Fox
Assigned To: Tim Fox
Fix For: 1.2.0.Beta1
We are currently executing unnecessary puts into the message store on the primary execution path of message routing.
When a new message arrives - it is first added to the message store. The message is only ever retrieved from the message store if a reference is loaded from paging and we want to make sure we do not have more than once instance in memory at once.
The first put is therefore unnecessary and will have some performance implications. Messages should only be added to the message store (if necessary) when they are paged to storage
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 11 months
[JBoss JIRA] Updated: (JBCACHE-11) Memory based eviction policy
by Alexandre Russel (JIRA)
[ http://jira.jboss.com/jira/browse/JBCACHE-11?page=all ]
Alexandre Russel updated JBCACHE-11:
------------------------------------
Attachment: memoryBaseEviction.txt
Hi,
a patch not meant to be comited but to get things started.
the idea is to separate:
when is there eviction => decided by EvictionTask.
which node is evicted => decided by the algorithm.
how many are evicted => decided by the number of nodes in the cache.
The patch keep the algoritm. It creates an abstract class EvictionTask,
with 2 child EvictionTimerTask (the previous EvictionTask) and
EvictionMemoryTask (a new EvictionTask based on memory).
I added setter and getter on EvictionPolicyConfig for maxNodes.
The EvictionMemoryTask listen to the memory pool that support usage threshold
and that matches a regexp given in config.
It accept 2 settings, a minimum and a maximum percentage of memory.
When there is a notification that the first minimum of memory is
exceded, the maximum number of nodes is set to half its value.
If it goes over the maximum percentage the maximum number of nodes goes to 1.
I used sun's jvm. If you run the test, you may want to check the number
of objects put in the list. It was set to be a raisonable value on my
computer.
If you think it is a good way to add memory based eviction, let me know
and I'll improve on it. (Few improvements would be to be able to increment
max nodes when memory is back to a low value and have more than just 2 values
max and min)
alex
> Memory based eviction policy
> ----------------------------
>
> Key: JBCACHE-11
> URL: http://jira.jboss.com/jira/browse/JBCACHE-11
> Project: JBoss Cache
> Issue Type: Feature Request
> Components: Eviction
> Reporter: Bela Ban
> Assigned To: Mircea Markus
> Fix For: 2.1.0.GA
>
> Attachments: memoryBaseEviction.txt
>
> Original Estimate: 2 weeks
> Remaining Estimate: 2 weeks
>
> (maybe only in JDK 1.5, which has
> triggers for low memory)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 11 months
[JBoss JIRA] Created: (JBAS-4092) Clean up the tests-webservice-ssl target
by Dimitris Andreadis (JIRA)
Clean up the tests-webservice-ssl target
----------------------------------------
Key: JBAS-4092
URL: http://jira.jboss.com/jira/browse/JBAS-4092
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Test Suite, Web Services
Reporter: Dimitris Andreadis
Assigned To: Thomas Diesler
Priority: Minor
Fix For: JBossAS-4.2.1.CR1
There is a server.xml file for the tests-webservice-ssl target. However, no tests actually get executed when you run this target. According to build.xml in testsuite, here are the tests it is trying to pull in:
<patternset id="webservice-ssl.includes">
<include name="org/jboss/test/webservice/secure/**/*TestCase.class"/>
<exclude name="org/jboss/test/webservice/secure/noenv/**/*TestCase.class"/>
</patternset>
So I guess the tests-webservice-ssl target is obsolete? Can someone from the Web Services team comment?
(see JBAS-4025)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 11 months
[JBoss JIRA] Created: (JBAS-3670) org.jboss.axis.ConfigurationException: No engine configuration file
by Keith Gregory (JIRA)
org.jboss.axis.ConfigurationException: No engine configuration file
-------------------------------------------------------------------
Key: JBAS-3670
URL: http://jira.jboss.com/jira/browse/JBAS-3670
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web Services
Affects Versions: JBossAS-4.0.3 SP1
Reporter: Keith Gregory
Assigned To: Thomas Diesler
Priority: Minor
The default org.jboss.axis.client.Service constructor will throw this exception. My particular case involves creating a new Service object from within an EJB, but this should occur with any client.
Tracing through the code, I discovered that org.jboss.axis.configuration.EngineConfigurationFactoryDefault defines the default filenames for the client configuration as "client-config.wsdd", while the actual file distributed with jboss-ws4ee-client.jar is "axis-client-config.xml". When the Service object is constructed, org.jboss.axis.configuration.FileProvider looks on the classpath for "client-config.wsdd", and of course can't find it.
The workaround specified in JBAS-1106 puts a file with the correct name but possibly the wrong configuration information onto the classpath, where FileProvider can find it. This will work for a standalone client, but not for client code within an EJB, since the Axis packages appear to be loaded with a different classloader than that for the EJB.
The workaround is to provide the Service constructor with a FileProvider that specifies the correct configuration file:
new Service(new FileProvider("META-INF/axis-client-config.xml"))
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 11 months
[JBoss JIRA] Created: (JBAS-3671) org.jboss.axis.ConfigurationException: No engine configuration file
by Keith Gregory (JIRA)
org.jboss.axis.ConfigurationException: No engine configuration file
-------------------------------------------------------------------
Key: JBAS-3671
URL: http://jira.jboss.com/jira/browse/JBAS-3671
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web Services
Affects Versions: JBossAS-4.0.3 SP1
Reporter: Keith Gregory
Assigned To: Thomas Diesler
Priority: Minor
The default org.jboss.axis.client.Service constructor will throw this exception. My particular case involves creating a new Service object from within an EJB, but this should occur with any client.
Tracing through the code, I discovered that org.jboss.axis.configuration.EngineConfigurationFactoryDefault defines the default filenames for the client configuration as "client-config.wsdd", while the actual file distributed with jboss-ws4ee-client.jar is "axis-client-config.xml". When the Service object is constructed, org.jboss.axis.configuration.FileProvider looks on the classpath for "client-config.wsdd", and of course can't find it.
The workaround specified in JBAS-1106 puts a file with the correct name but possibly the wrong configuration information onto the classpath, where FileProvider can find it. This will work for a standalone client, but not for client code within an EJB, since the Axis packages appear to be loaded with a different classloader than that for the EJB.
The workaround is to provide the Service constructor with a FileProvider that specifies the correct configuration file:
new Service(new FileProvider("META-INF/axis-client-config.xml"))
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 11 months
[JBoss JIRA] Created: (JBAS-3960) Web Service Test case failed in JBoss AS 4.0.5GA
by Steven lian (JIRA)
Web Service Test case failed in JBoss AS 4.0.5GA
------------------------------------------------
Key: JBAS-3960
URL: http://jira.jboss.com/jira/browse/JBAS-3960
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web Services
Affects Versions: JBossAS-4.0.5.GA
Environment: Arch: x86_64
OS: RHEL4U4
JVM: Sun jdk version "1.5.0_06"
JBoss Version: JBoss AS 4.0.5 GA and JBoss AS 4.0.5 GA src
Reporter: Steven lian
Assigned To: Thomas Diesler
Fix For: JBossAS-4.0.4.CR2
When running JBoss AS testsuite,the testcase org.jboss.test.webservice.secure.SimpleClientSecureTestCase and org.jboss.test.webservice.secure.noenv.TransportOptionsTestCase is failed for the exceptions.
reproduce steps:
1.build jboss AS 4.0.5 src and start JBoss server with all configuration
2.cd $JBOSS_HOME_SRC/testsuite
3.ant onte-test -Dtest=org.jboss.test.webservice.secure.SimpleClientSecureTestCase
4.ant onte-test -Dtest=org.jboss.test.webservice.secure.noenv.TransportOptionsTestCase
Result:
Buildfile: build.xml
one-test:
[delete] Deleting: /root/jboss-4.0.5.GA-src/testsuite/output/log/test.log
[junit] Running org.jboss.test.webservice.secure.noenv.TransportOptionsTestCase
[junit] Tests run: 2, Failures: 0, Errors: 1, Time elapsed: 3.502 sec
[junit] Test org.jboss.test.webservice.secure.noenv.TransportOptionsTestCase FAILED
one-test:
[delete] Deleting: /root/jboss-4.0.5.GA-src/testsuite/output/log/test.log
[junit] Running org.jboss.test.webservice.secure.SimpleClientSecureTestCase
[junit] Tests run: 2, Failures: 0, Errors: 2, Time elapsed: 3.934 sec
[junit] Test org.jboss.test.webservice.secure.SimpleClientSecureTestCase FAILED
The test log :
Testcase: testWithTransportOptions took 1.934 sec
Caused an ERROR
Call invocation failed: Could not transmit message; nested exception is:
javax.xml.soap.SOAPException: Could not transmit message
java.rmi.RemoteException: Call invocation failed: Could not transmit message; nested exception is:
javax.xml.soap.SOAPException: Could not transmit message
at org.jboss.ws.jaxrpc.CallImpl.invokeInternal(CallImpl.java:718)
at org.jboss.ws.jaxrpc.CallImpl.invoke(CallImpl.java:404)
at org.jboss.ws.jaxrpc.CallProxy.invoke(CallProxy.java:148)
at $Proxy3.sayHello(Unknown Source)
at org.jboss.test.webservice.secure.noenv.TransportOptionsTestCase.testWithTransportOptions(TransportOptionsTestCase.java:90)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
Caused by: javax.xml.soap.SOAPException: Could not transmit message
at org.jboss.ws.soap.SOAPConnectionImpl.call(SOAPConnectionImpl.java:204)
at org.jboss.ws.jaxrpc.CallImpl.invokeInternal(CallImpl.java:687)
... 23 more
Caused by: org.jboss.remoting.CannotConnectException: Can not connect http client invoker.
at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:201)
at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:81)
at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143)
at org.jboss.remoting.Client.invoke(Client.java:525)
at org.jboss.remoting.Client.invoke(Client.java:488)
at org.jboss.ws.soap.SOAPConnectionImpl.call(SOAPConnectionImpl.java:189)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 11 months
[JBoss JIRA] Created: (JBAS-3844) "array element type mismatch" when deserializing JAX-RPC value type properties of array type when size >2
by Andrei Iltchenko (JIRA)
"array element type mismatch" when deserializing JAX-RPC value type properties of array type when size >2
-----------------------------------------------------------------------------------------------------------
Key: JBAS-3844
URL: http://jira.jboss.com/jira/browse/JBAS-3844
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web Services
Affects Versions: JBossAS-4.0.3 SP1
Reporter: Andrei Iltchenko
Assigned To: Thomas Diesler
We experience a problem with the WS4EE stack on JBoss 4.0.3 when deserializing JAX-RPC value type properties of array type when the number of elements is greater than 2 and when the request envelope was created by a .NET client. There are similar issues reported on AXIS. Here's a typical stack trace we get:
14:59:13,330 ERROR [BeanPropertyTarget] Could not convert [Lcrm.application.business.common.customersvc.CallDataObject; to bean field 'typedElements[2]', type [Lcrm.application.business.common.customersvc.CallDataObject;
14:59:13,390 ERROR [RPCInvocation] java.lang.IllegalArgumentException: array element type mismatch
java.lang.IllegalArgumentException: array element type mismatch
at org.jboss.axis.encoding.ser.BeanPropertyTarget.set(BeanPropertyTarget.java:243)
at org.jboss.axis.encoding.DeserializerImpl.valueComplete(DeserializerImpl.java:305)
at org.jboss.axis.encoding.DeserializerImpl.endElement(DeserializerImpl.java:590)
at org.jboss.axis.encoding.DeserializationContextImpl.endElement(DeserializationContextImpl.java:1269)
at org.jboss.axis.message.SAX2EventRecorder.replay(SAX2EventRecorder.java:252)
at org.jboss.axis.message.SOAPElementAxisImpl.publishToHandler(SOAPElementAxisImpl.java:1394)
at org.jboss.axis.message.RPCElement.deserialize(RPCElement.java:266)
at org.jboss.axis.message.RPCElement.getParams(RPCElement.java:402)
at org.jboss.axis.providers.java.RPCInvocation.prepareFromRequestEnvelope(RPCInvocation.java:235)
at org.jboss.axis.providers.java.RPCProvider.processMessage(RPCProvider.java:103)
at org.jboss.axis.providers.java.JavaProvider.invoke(JavaProvider.java:358)
at org.jboss.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:73)
at org.jboss.axis.SimpleChain.doVisiting(SimpleChain.java:160)
at org.jboss.axis.SimpleChain.invoke(SimpleChain.java:123)
at org.jboss.axis.handlers.soap.SOAPService.invoke(SOAPService.java:560)
at org.jboss.webservice.server.ServerEngine.invokeInternal(ServerEngine.java:215)
at org.jboss.webservice.server.ServerEngine.invoke(ServerEngine.java:104)
at org.jboss.axis.transport.http.AxisServlet.doPost(AxisServlet.java:911)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.jboss.axis.transport.http.AxisServletBase.service(AxisServletBase.java:370)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Thread.java:595)
Message:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext..." xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utilit...">
<soap:Header>
<wsa:Action>
</wsa:Action>
<wsa:MessageID>urn:uuid:6bdec88b-6594-4cae-81a5-628b86b75699</wsa:MessageID>
<wsa:ReplyTo>
<wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>
</wsa:ReplyTo>
<wsa:To>http://localhost:8082/ws/customersvc</wsa:To>
<wsse:Security>
<wsu:Timestamp wsu:Id="Timestamp-b935bb5d-4a72-4b8d-ba5d-d529e18cc23e">
<wsu:Created>2006-11-10T13:59:13Z</wsu:Created>
<wsu:Expires>2006-11-10T14:04:13Z</wsu:Expires>
</wsu:Timestamp>
</wsse:Security>
</soap:Header>
<soap:Body>
<setCustomerDo xmlns="http://logic.business.application.crm">
<update xmlns="">
<deleted>false</deleted>
<created>true</created>
<pruned>true</pruned>
<Original xsi:nil="true" />
<CRC>0</CRC>
<customerId>0002</customerId>
<contractDate>2006-11-07T00:00:00</contractDate>
<call>
<typedElements>
<deleted>false</deleted>
<created>true</created>
<pruned>true</pruned>
<Original xsi:nil="true" />
<CRC>0</CRC>
<callResolved>false</callResolved>
<callDescription xsi:nil="true" />
<callTimestamp>0001-01-01T00:00:00</callTimestamp>
</typedElements>
<typedElements>
<deleted>false</deleted>
<created>true</created>
<pruned>true</pruned>
<Original xsi:nil="true" />
<CRC>0</CRC>
<callResolved>false</callResolved>
<callDescription xsi:nil="true" />
<callTimestamp>0001-01-01T00:00:00</callTimestamp>
</typedElements>
<typedElements>
<deleted>false</deleted>
<created>true</created>
<pruned>true</pruned>
<Original xsi:nil="true" />
<CRC>0</CRC>
<callResolved>false</callResolved>
<callDescription xsi:nil="true" />
<callTimestamp>0001-01-01T00:00:00</callTimestamp>
</typedElements>
</call>
<firstName>Andre</firstName>
<serviceAgreement>
<deleted>false</deleted>
<created>true</created>
<pruned>true</pruned>
<Original xsi:nil="true" />
<CRC>0</CRC>
<serviceLevel>
<value>1</value>
</serviceLevel>
<saDescription>Medium Service</saDescription>
<saPrice>50.95</saPrice>
<customer />
<saId>0001</saId>
</serviceAgreement>
<customerTitle>Mr</customerTitle>
<lastName>Bos</lastName>
<address>
<countryCode>31</countryCode>
<phone xsi:nil="true" />
<zipCode>1005 BB</zipCode>
<street>Hoogoorddreef</street>
<city>Amsterdam</city>
<stateCode xsi:nil="true" />
<email>Reinier.Bos(a)nl.compuware.com</email>
</address>
</update>
</setCustomerDo>
</soap:Body>
</soap:Envelope>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 11 months