[JBoss JIRA] (WFLY-5242) Inconsistent format for IPv6 addresses in server log
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-5242?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-5242:
-----------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1260566|https://bugzilla.redhat.com/show_bug.cgi?id=1260566] from MODIFIED to ON_QA
> Inconsistent format for IPv6 addresses in server log
> ----------------------------------------------------
>
> Key: WFLY-5242
> URL: https://issues.jboss.org/browse/WFLY-5242
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Beta2
> Reporter: Lyle Wang
> Assignee: Chao Wang
> Priority: Minor
> Fix For: 10.0.0.CR1
>
>
> Description of problem:
> When IPv6 is used, square brackets for IPv6 addresses are missed in some of log entries. Specifically, the address format from Undertow logs is different from those "WFLYSRV" logs.
> How reproducible:
> Always
> Steps to Reproduce:
> 1. Config IPv6 (example: https://docs.jboss.org/author/display/WFLY10/Interfaces+and+ports)
> 2. Start WildFly and check the log
> Actual results:
> ----------------------------------------
> 2015-08-31 12:51:47,812 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0006: Undertow HTTP listener default listening on /0:0:0:0:0:0:0:1:8080
> ......
> 2015-08-31 12:51:48,431 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[::1]:9993/management
> 2015-08-31 12:51:48,432 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[::1]:9993
> ----------------------------------------
> In Undertow logs it's like "/0:0:0:0:0:0:0:1:8080" but in WildFly server logs "http://[::1]:9993/management"
> Expected results:
> Consistent format should be used for IPv6 address across different components and the address is enclosed in square brackets [ ].
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (ELY-358) Wrap all LDAP testing in a single suite
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-358?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina commented on ELY-358:
--------------------------------
Note: by moving server start into testsuite decreased build time *from 2m:10s to 1m:40s*
> Wrap all LDAP testing in a single suite
> ---------------------------------------
>
> Key: ELY-358
> URL: https://issues.jboss.org/browse/ELY-358
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Testsuite
> Reporter: Darran Lofthouse
> Assignee: Jan Kalina
> Fix For: 1.1.0.Beta5
>
>
> If we wrap all these tests in a single suite we can start up the LDAP server one, run all the tests and then stop the server - this will stop us incurring the set-up / tear-down cost for each test case.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (ELY-358) Wrap all LDAP testing in a single suite
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-358?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina edited comment on ELY-358 at 2/24/16 2:44 PM:
---------------------------------------------------------
Note: by moving server start into testsuite decreased build time from *2m:10s* to *1m:40s*
was (Author: honza889):
Note: by moving server start into testsuite decreased build time *from 2m:10s to 1m:40s*
> Wrap all LDAP testing in a single suite
> ---------------------------------------
>
> Key: ELY-358
> URL: https://issues.jboss.org/browse/ELY-358
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Testsuite
> Reporter: Darran Lofthouse
> Assignee: Jan Kalina
> Fix For: 1.1.0.Beta5
>
>
> If we wrap all these tests in a single suite we can start up the LDAP server one, run all the tests and then stop the server - this will stop us incurring the set-up / tear-down cost for each test case.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (DROOLS-507) Cannot issue fireUntilHalt when using persisted session
by Michael Neifeld (JIRA)
[ https://issues.jboss.org/browse/DROOLS-507?page=com.atlassian.jira.plugin... ]
Michael Neifeld edited comment on DROOLS-507 at 2/24/16 12:03 PM:
------------------------------------------------------------------
I also faced the same issue in the Drools 6.3.0.Final.
It doesn't seem to me the reason is obvious - this command has the meaning only in the stateful session and if it has to be available for 24/7 and thus must be backed up by persistence.
Also, I can see another purpose - for example, of the huge event stream, might be very useful to bring up a number of stateful sessions that can be synchronized by common persistence.
IMHO, this is "must have" feature.
was (Author: newfield):
I also faced the same issue in the Drools 6.3.0.Final.
It doesn't seem to me the reason is obvious - this command has the meaning only in the stateful session and if it has to be available for 24/7 and thus must be backed up by persistence.
Also, I can see another purpose - for example, of the huge event stream, might be very useful to bring up a number of stateful sessions that can be synchronized by common persistence.
IMHO, this is must have feature.
> Cannot issue fireUntilHalt when using persisted session
> -------------------------------------------------------
>
> Key: DROOLS-507
> URL: https://issues.jboss.org/browse/DROOLS-507
> Project: Drools
> Issue Type: Feature Request
> Affects Versions: 6.1.0.Beta3
> Environment: Mac OSX Maverick, Spring 4.0.1
> Reporter: Roger Lefebvre
> Assignee: Mark Proctor
>
> Generating the following exception when using runUntilHalt() with persistence.
> Exception in thread "SimpleAsyncTaskExecutor-1" java.lang.UnsupportedOperationException: Command session.fireUntilHalt(); cannot be issued on a persisted session at org.drools.persistence.SingleSessionCommandService$TransactionInterceptor.execute(SingleSessionCommandService.java:474) at org.drools.persistence.SingleSessionCommandService.execute(SingleSessionCommandService.java:353) at org.drools.core.command.impl.CommandBasedStatefulKnowledgeSession.fireUntilHalt(CommandBasedStatefulKnowledgeSession.java:272) at com.s.c.m.CallHandler$RunEngine.run(CallHandler.java:115) at java.lang.Thread.run(Thread.java:722)
> Persistence and KieSession defined in Spring as follows:
> <!-- provides KnowledgeStoreService implementation -->
> <kie:kstore id="kstore"/>
> <bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
> <property name="driverClassName" value="com.mysql.jdbc.Driver" />
> <property name="url" value="jdbc:mysql://localhost:3306/ruleEngine" />
> <property name="username" value="xxxxxx" /> <property name="password" value="yyyyyyyy" />
> </bean>
> <bean id="emf" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
> <property name="dataSource" ref="dataSource"/>
> <property name="persistenceUnitName" value="org.drools.persistence.jpa.local"/>
> </bean>
> <bean id="txManager" class="org.springframework.orm.jpa.JpaTransactionManager">
> <property name="entityManagerFactory" ref="emf"/>
> </bean>
> <kie:kmodule id="callManagerModule">
> <kie:kbase name="commandKBase" packages="rules.command" eventProcessingMode="stream">
> <kie:ksession name="commandEngine" type="stateful"></kie:ksession>
> </kie:kbase>
> <kie:kbase name="campaignKBase" packages="rules.campaign.*" eventProcessingMode="stream" equalsBehavior="equality">
> <kie:ksession name="campaignEngine" type="stateful" >
> <kie:consoleLogger/>
> <kie:configuration>
> <kie:jpa-persistence>
> <kie:transaction-manager ref="txManager"/>
> <kie:entity-manager-factory ref="emf"/>
> </kie:jpa-persistence>
> </kie:configuration>
> </kie:ksession>
> </kie:kbase>
> </kie:kmodule>
> <bean id="taskExecutor" class="org.springframework.core.task.SimpleAsyncTaskExecutor">
> <property name="daemon" value="true"/>
> </bean>
> <bean id="campaignHandler" class="com.s.c.m.CallHandler" init-method="init">
> <constructor-arg type="org.springframework.core.task.TaskExecutor" ref="taskExecutor"/>
> </bean>
> I invoke fireUntilHalt method as follows:
>
> private TaskExecutor taskExecutor;
> public CampaignCallHandler(TaskExecutor taskExecutor) {
> this.taskExecutor = taskExecutor; }
> public void init() { taskExecutor.execute(new RunEngine()); }
> class RunEngine implements Runnable {
> @Override public void run() { campaignEngine.fireUntilHalt(); } }
> NOTE: This occurs on a new system where nothing has been persisted to the database. In other words, there isn't a session available to be loaded. I have yet to have success reloading a session - that is a separate issue that I believe DROOLS-422 partially identifies.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (DROOLS-507) Cannot issue fireUntilHalt when using persisted session
by Michael Neifeld (JIRA)
[ https://issues.jboss.org/browse/DROOLS-507?page=com.atlassian.jira.plugin... ]
Michael Neifeld edited comment on DROOLS-507 at 2/24/16 12:02 PM:
------------------------------------------------------------------
I also faced the same issue in the Drools 6.3.0.Final.
It doesn't seem to me the reason is obvious - this command has the meaning only in the stateful session and if it has to be available for 24/7 and thus must be backed up by persistence.
Also, I can see another purpose - for example, of the huge event stream, might be very useful to bring up a number of stateful sessions that can be synchronized by common persistence.
IMHO, this is must have feature.
was (Author: newfield):
I also faced the same issue in the Drools 6.3.0.Final.
It doesn't seem to me the reason is obvious - this command has the meaning only in the stateful session and if it has to be available for 24/7 and this way must be backed up by persistence.
Also, I can see another purpose - for example, of the huge event stream, might be very useful to bring up a number of stateful sessions that can be synchronized by common persistence.
IMHO, this is must have feature.
> Cannot issue fireUntilHalt when using persisted session
> -------------------------------------------------------
>
> Key: DROOLS-507
> URL: https://issues.jboss.org/browse/DROOLS-507
> Project: Drools
> Issue Type: Feature Request
> Affects Versions: 6.1.0.Beta3
> Environment: Mac OSX Maverick, Spring 4.0.1
> Reporter: Roger Lefebvre
> Assignee: Mark Proctor
>
> Generating the following exception when using runUntilHalt() with persistence.
> Exception in thread "SimpleAsyncTaskExecutor-1" java.lang.UnsupportedOperationException: Command session.fireUntilHalt(); cannot be issued on a persisted session at org.drools.persistence.SingleSessionCommandService$TransactionInterceptor.execute(SingleSessionCommandService.java:474) at org.drools.persistence.SingleSessionCommandService.execute(SingleSessionCommandService.java:353) at org.drools.core.command.impl.CommandBasedStatefulKnowledgeSession.fireUntilHalt(CommandBasedStatefulKnowledgeSession.java:272) at com.s.c.m.CallHandler$RunEngine.run(CallHandler.java:115) at java.lang.Thread.run(Thread.java:722)
> Persistence and KieSession defined in Spring as follows:
> <!-- provides KnowledgeStoreService implementation -->
> <kie:kstore id="kstore"/>
> <bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
> <property name="driverClassName" value="com.mysql.jdbc.Driver" />
> <property name="url" value="jdbc:mysql://localhost:3306/ruleEngine" />
> <property name="username" value="xxxxxx" /> <property name="password" value="yyyyyyyy" />
> </bean>
> <bean id="emf" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
> <property name="dataSource" ref="dataSource"/>
> <property name="persistenceUnitName" value="org.drools.persistence.jpa.local"/>
> </bean>
> <bean id="txManager" class="org.springframework.orm.jpa.JpaTransactionManager">
> <property name="entityManagerFactory" ref="emf"/>
> </bean>
> <kie:kmodule id="callManagerModule">
> <kie:kbase name="commandKBase" packages="rules.command" eventProcessingMode="stream">
> <kie:ksession name="commandEngine" type="stateful"></kie:ksession>
> </kie:kbase>
> <kie:kbase name="campaignKBase" packages="rules.campaign.*" eventProcessingMode="stream" equalsBehavior="equality">
> <kie:ksession name="campaignEngine" type="stateful" >
> <kie:consoleLogger/>
> <kie:configuration>
> <kie:jpa-persistence>
> <kie:transaction-manager ref="txManager"/>
> <kie:entity-manager-factory ref="emf"/>
> </kie:jpa-persistence>
> </kie:configuration>
> </kie:ksession>
> </kie:kbase>
> </kie:kmodule>
> <bean id="taskExecutor" class="org.springframework.core.task.SimpleAsyncTaskExecutor">
> <property name="daemon" value="true"/>
> </bean>
> <bean id="campaignHandler" class="com.s.c.m.CallHandler" init-method="init">
> <constructor-arg type="org.springframework.core.task.TaskExecutor" ref="taskExecutor"/>
> </bean>
> I invoke fireUntilHalt method as follows:
>
> private TaskExecutor taskExecutor;
> public CampaignCallHandler(TaskExecutor taskExecutor) {
> this.taskExecutor = taskExecutor; }
> public void init() { taskExecutor.execute(new RunEngine()); }
> class RunEngine implements Runnable {
> @Override public void run() { campaignEngine.fireUntilHalt(); } }
> NOTE: This occurs on a new system where nothing has been persisted to the database. In other words, there isn't a session available to be loaded. I have yet to have success reloading a session - that is a separate issue that I believe DROOLS-422 partially identifies.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (DROOLS-507) Cannot issue fireUntilHalt when using persisted session
by Michael Neifeld (JIRA)
[ https://issues.jboss.org/browse/DROOLS-507?page=com.atlassian.jira.plugin... ]
Michael Neifeld commented on DROOLS-507:
----------------------------------------
I also faced the same issue in the Drools 6.3.0.Final.
It doesn't seem to me the reason is obvious - this command has the meaning only in the stateful session and if it has to be available for 24/7 and this way must be backed up by persistence.
Also, I can see another purpose - for example, of the huge event stream, might be very useful to bring up a number of stateful sessions that can be synchronized by common persistence.
IMHO, this is must have feature.
> Cannot issue fireUntilHalt when using persisted session
> -------------------------------------------------------
>
> Key: DROOLS-507
> URL: https://issues.jboss.org/browse/DROOLS-507
> Project: Drools
> Issue Type: Feature Request
> Affects Versions: 6.1.0.Beta3
> Environment: Mac OSX Maverick, Spring 4.0.1
> Reporter: Roger Lefebvre
> Assignee: Mark Proctor
>
> Generating the following exception when using runUntilHalt() with persistence.
> Exception in thread "SimpleAsyncTaskExecutor-1" java.lang.UnsupportedOperationException: Command session.fireUntilHalt(); cannot be issued on a persisted session at org.drools.persistence.SingleSessionCommandService$TransactionInterceptor.execute(SingleSessionCommandService.java:474) at org.drools.persistence.SingleSessionCommandService.execute(SingleSessionCommandService.java:353) at org.drools.core.command.impl.CommandBasedStatefulKnowledgeSession.fireUntilHalt(CommandBasedStatefulKnowledgeSession.java:272) at com.s.c.m.CallHandler$RunEngine.run(CallHandler.java:115) at java.lang.Thread.run(Thread.java:722)
> Persistence and KieSession defined in Spring as follows:
> <!-- provides KnowledgeStoreService implementation -->
> <kie:kstore id="kstore"/>
> <bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
> <property name="driverClassName" value="com.mysql.jdbc.Driver" />
> <property name="url" value="jdbc:mysql://localhost:3306/ruleEngine" />
> <property name="username" value="xxxxxx" /> <property name="password" value="yyyyyyyy" />
> </bean>
> <bean id="emf" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
> <property name="dataSource" ref="dataSource"/>
> <property name="persistenceUnitName" value="org.drools.persistence.jpa.local"/>
> </bean>
> <bean id="txManager" class="org.springframework.orm.jpa.JpaTransactionManager">
> <property name="entityManagerFactory" ref="emf"/>
> </bean>
> <kie:kmodule id="callManagerModule">
> <kie:kbase name="commandKBase" packages="rules.command" eventProcessingMode="stream">
> <kie:ksession name="commandEngine" type="stateful"></kie:ksession>
> </kie:kbase>
> <kie:kbase name="campaignKBase" packages="rules.campaign.*" eventProcessingMode="stream" equalsBehavior="equality">
> <kie:ksession name="campaignEngine" type="stateful" >
> <kie:consoleLogger/>
> <kie:configuration>
> <kie:jpa-persistence>
> <kie:transaction-manager ref="txManager"/>
> <kie:entity-manager-factory ref="emf"/>
> </kie:jpa-persistence>
> </kie:configuration>
> </kie:ksession>
> </kie:kbase>
> </kie:kmodule>
> <bean id="taskExecutor" class="org.springframework.core.task.SimpleAsyncTaskExecutor">
> <property name="daemon" value="true"/>
> </bean>
> <bean id="campaignHandler" class="com.s.c.m.CallHandler" init-method="init">
> <constructor-arg type="org.springframework.core.task.TaskExecutor" ref="taskExecutor"/>
> </bean>
> I invoke fireUntilHalt method as follows:
>
> private TaskExecutor taskExecutor;
> public CampaignCallHandler(TaskExecutor taskExecutor) {
> this.taskExecutor = taskExecutor; }
> public void init() { taskExecutor.execute(new RunEngine()); }
> class RunEngine implements Runnable {
> @Override public void run() { campaignEngine.fireUntilHalt(); } }
> NOTE: This occurs on a new system where nothing has been persisted to the database. In other words, there isn't a session available to be loaded. I have yet to have success reloading a session - that is a separate issue that I believe DROOLS-422 partially identifies.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months